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Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Conmiittee Electromagnetic compatibility and 
Radio spectrum Matters (ERM). 

The present document is part 4 of a multi-part deliverable covering the Technical Requirements for Digital Mobile 
Radio (DMR), as identified below: 

Part 1 : "DMR Air Interface (AI) protocol" ; 

Part 2: "DMR voice and generic services and facilities"; 

Part 3 : "DMR data protocol" ; 

Part 4: "DMR trunking protocol". 
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Scope 



The present document contains technical requirements for Digital Mobile Radio (DMR) trunking systems operating in 
the existing licensed land mobile service frequency bands, as identified in CEPT/ERC/T/R 25-08 [10]. 

The present document describes the trunking services and facilities protocol of a scalable Digital Mobile Radio system, 
which covers three tiers of possible products: 

Tier I: DMR equipment having an integral antenna and working in Direct Mode (unit-to-unit) under a 

general authorization with no individual rights operation. 

Tier II: DMR systems operating under individual licences working in Direct Mode (unit-to-unit) or using a 

Base Station (BS) for repeating. 

Tier III: DMR trunking systems under individual licences operating with a controller function that 

automatically regulates the communications. 

NOTE: Tier II and Tier III products encompass both simulcast and non-simulcast systems. 

The DMR air interface complies with either EN 300 113-1 [1], EN 300 113-2 [2] or EN 300 390-1 [3], 

EN 300 390-2 [4], that has been specifically developed with the intention of being suitable for all identified product 

tiers. 

The DMR protocol is intended to be applicable to the land mobile service frequency bands, physical channel offset, 
duplex spacing, range assumptions and all other spectrum parameters without need for any change. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

l:l-mode: 1 payload channel mode 

NOTE: l:l-mode supports one "MS to fixed end" duplex call or one simplex call with an optional inbound 
Reverse Channel using a two frequency BS. 

2:l-mode: 2 payload channel mode 

NOTE: 2:1 -mode supports two independent calls which may be either "MS to fixed end" duplex calls or simplex 
calls using a two frequency BS. 

assigned channel: channel that has been allocated by the infrastructure to certain MSs using channel allocation 
command(s) addressed to those MSs 

NOTE: An assigned channel may be allocated for secondary control purposes or for a circuit mode call. 

asynchronous access: mode of operation whereby MS are permitted access to TS by employing the polite protocol 
defined in TS 102 361-2 [6] 

NOTE: In this mode MS are not required to listen to a TSCC to first determine their access rights. 

Base Station (BS): fixed end equipment that is used to obtain DMR services 

bearer service: telecommunication service providing the capability for information transfer between access points 

burst: elementary amount of bits within the physical channel 

NOTE 1 : The burst may include a guard time at the beginning and end of the burst used for power ramp-up and 
ramp-down. 

NOTE 2: Two bursts with different length are defined for DMR. A TDMA bursts which has a length of 30 ms and 
a Reverse Channel burst which has a length of 10 ms. 

NOTE 3: For detailed burst definition see TS 102 361-1 [5], clause 4.2.1. 
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NOTE 4: A burst represents the physical content (channel) of a timeslot. 
call: complete sequence of related transactions between MSs 

NOTE: Transactions may be one or more bursts containing specific call related information. 

Caller Line Identity (CLI): ability to see who is calling you before answering the telephone 

channel: in the Time Division Multiple Access (TDMA) slot structure arrangement a channel comprises the pair of 
same numbered slots on the inbound and outbound duplex frequencies 

composite control channel: TSCC that may temporarily revert to a payload channel (if for instance the instantaneous 
traffic exceeds that which may be accommodated by the available payload channels) 

Control plane (C-plane): part of the DMR protocol stack dedicated to control and data services 

coverage area: geographical area within which the received signal strength from a radiating BS exceeds a specified 
threshold value 

dedicated control channel: TSCC that is continuously transmitted by a TS and never reverts to a payload channel 

Digital Mobile Radio (DMR): physical grouping that contains all of the mobile and/or fixed end equipment that is 
used to obtain DMR services 

direct mode: mode of operation where MSs may communicate outside the control of a network 

NOTE: This is communication technique where any MS (MS) may communicate with one or more other MSs 
(MSs) without the need for any additional equipment (e.g. BS). 

duplex: mode of operation by which information can be transferred in both directions and where the two directions are 
independent 

NOTE: Duplex is also known as full duplex. 

extended address: source or destination that is not an MS address (such as a PABX extension, PSTN number or IP 
address) 

Supplementary Data Transfer Service: service to transfer supplementary data between DMR MS or MS/TS entities 
connected through gateways 

First In First Out (FIFO): storage type that retrieves information in the order in which it was stored 

fixed non- volatile storage: storage facility within a MS, the contents of which cannot be modified or added to by the 
operation of the MS or its user 

high-rate: Packet Data Transmission that uses dual slot data timing 

inbound: MS to BS transmission 

information element: subset (field) within a PDU 

intrinsic service: service which is inherent within a voice or data service 

NOTE: It forms an integral part of the signalling associated with that voice or data service. 

item: MS payload transmission from the point at which the PTT is pressed to the PTT released 

line connected: call whereby one end of the call is connected to the radio system that does not use the DMR Air 
Interface 

NOTE: Examples may be connection to the PSTN or a PABX. 

logical channel: distinct data path between logical endpoints 

message trunking: mode of operation that a payload channel is permanently allocated for the complete duration of the 
call, which may include several separate PTT items (several PTT activations by separate terminals) 

NOTE: The channel is only de-allocated if the call is (explicitly) released or if a time-out expires. 
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Mobile Station (MS): physical grouping that contains all of the mobile equipment that is used to obtain DMR mobile 
services 

multi-part call set-up: call set-up procedure whereby the full source and destination address cannot be accommodated 
in a single CSBK signalling block 

NOTE: The UDT procedure is invoked to transfer the address information using Multi Block Control (UDT) 
signalling. UDT is also invoked to transport supplementary and user data between DMR entities. 

network personalization: configuration parameters appropriate to network configuration programmed into a MS that 
may be set by an external agency but not by the user of an MS 

non- volatile storage: readAVrite storage that stores information during operation of a MS that is protected from the 
effects of switching off the MS 

outbound: BS to MS transmission 

packet data: method for the transmission of information by which the information is transmitted as packets each 
containing a fragment of the total information to be transmitted 

PARtition (PAR): Information Element used to partition MSs on a TS that implements two control channels (TSCCs) 

payload: bits in the information field 

personalization: configuration parameters that may be set by an external agency but not by the user of an MS 

physical channel: TDM A burst 

NOTE: The DMR radio frequency channel contains two physical channels. 

polite protocol: "Listen Before Transmit" (LBT) protocol 

NOTE: This is a medium access protocol that implements a LBT function in order to ensure that the channel is 
free before transmitting. 

power-save-frame: sixteen time slots (480 ms) defining a period for sleeping MS to wake 

privacy: secret transformation 

NOTE: Any transformation of transmitted information that is derived from a shared secret between the sender and 
receiver. 

Protocol Data Unit (PDU): unit of information consisting of protocol control information (signalling) and possibly 
user data exchanged between peer protocol layer entities 

radio frequency channel: radio frequency carrier (RF carrier) 

NOTE: This is a specified portion of the RF spectrum. In DMR, the RF carrier separation is 12,5 kHz. The 
physical channel may be a single frequency or a duplex spaced pair of frequencies. 

random access attempt: period from the initiation of the random access procedure until the MS receives a response 
from the BS or abandons the procedure (e.g. after sending the maximum permitted number of retries) 

read write storage: storage facility within the MS the contents of which may be modified by the operation of the MS. 
The stored data is lost when the MS is switched off 

Received Signal Strength Indication (RSSI): root mean squared (rms) value of the signal received at the receiver 
antenna 

registration (MS view): network procedure whereby the MS asks for and the TSCC grants access to a particular MS. 
The MS is required to inform the system whenever it enters a new registration area 

serving site: radio site that is currently proving service to the MS 

signalling: exchange of information specifically concerned with the establishment and control of connections, and with 
management, in a telecommunication network 
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simplex: mode of working by which information can be transferred in both directions but not at the same time 

NOTE: Simplex is also known as half duplex. 

single-part call set-up: call set-up procedure whereby the full source and destination address is accommodated in a 
single CSBK signalling block 

site: totality of BSs and trunk site control equipment that processes calls in one location 

slot: See time-slot. 

superframe: 6 continuous TDM A bursts labelled "A" to "F" 

NOTE: A superframe has a length of 360 ms and is used for voice payload only. 
TDMA-frame: two continuous time-slots 
time-slot: elementary time unit for allocation of a burst 

NOTE: A timeslot has a length of 30 ms. 

transmission: transfer period of bursts containing information or signalling 

NOTE: The transmission may be continuous, i.e. multiple bursts transmission without ramp-up, ramp-down, or 
discontinuous, i.e. single burst transmission with ramp-up and ramp-down period. 

transmission trunking: mode of operation that a payload channel is individually allocated for each call transaction (for 
each activation of the PTT) 

NOTE: The channel is immediately de-allocated at the end of the call transaction (subject to unavoidable protocol 
delays). 

Trunked Station (TS): physical grouping that contains all of the fixed end equipment in one location that is used to 
obtain DMR Tier III services 

Trunk Station Control Channel (TSCC): control channel transmitted by the infrastructure to control the MS 
population 

TS Authorization: complete procedure whereby a MS tests the System Identity code and an optional step of 
authentication to ascertain if it is permitted to gain access 

Unified Data Transport: universal methodology used to transport data in DMR systems 

user plane (U-plane): part of the DMR protocol stack dedicated to user voice services 

vocoder socket: 216 bits vocoder payload 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

Hz absolute frequency 

Nibble 4 bits grouped together 

Octet 8 bits grouped together, also called a byte 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 



AI 


Air Interface 


BCD 


Binary Coded Decimal 


BER 


Bit Error Rate 


BS 


Base Station 



NOTE: A reference designating a fixed end device. 
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CACH 


Common Announcement CHannel 


CC 


Colour Code 


CCL 


Call Control Layer 


CLI 


Caller Line Identity 


C-plane 


Control-plane 


CRC 


Cyclic Redundancy Checksum for data error detection 


CSBK 


Control Signalling BlocK 


CSBKO 


CSBK Opcode 


DLL 


Data Link Layer 


DMR 


Digital Mobile Radio 


FEC 


Forward Error Correction 


FID 


Feature set ID 


FIFO 


First In First Out 


ID 


IDentifier 


IP 


Internet Protocol 


LB 


Last Block 


LBT 


Listen Before Transmit 


LC 


Link Control 


MBC 


Multiple Block Control packets 


MS 


Mobile Station 


NOTE: 


A reference designating a mobile or portable radio. 


MSB 


Most Significant Bit 


MSC 


Message Sequence Chart 


PABX 


Private Automatic Branch eXchange 


PAR 


PARtition 


PDU 


Protocol Data Unit 


PF 


Protect Flag 


PL 


Physical Layer 


PSTN 


Public Switched Telephone Network 


PTT 


Push To Talk 


RC 


Reverse Channel 


RF 


Radio Frequency 


RSSI 


Received Signal Strength Indication 


SAP 


Service Access Point 


NOTE: 


Where a network provides a service. 


SDL 


Specification and Description Language 


SFID 


Standard FID 


SLCO 


Short LC Opcode 


SYNC 


SYNChronization 


TDMA 


Time Division Multiple Access 


TS 


Trunked Station 


TSCC 


Trunk Station Control Channel 


UAB 


UDT Appended Blocks 


UDT 


Unified Data Transport 


Unicode 


16 bit character encoding 


U-plane 


User-plane 



Overview 



The present document describes a Digital Mobile Radio (DMR) protocol for Tier III trunked mobile radio systems that 
employ a Time Division Multiple Access (TDMA) technology with a 2-slot TDMA solution and RF carrier bandwidth 
of 12,5 kHz. 
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Radio equipments (fixed, mobile or portable), which conform to the present document shall be interoperable with 
equipment from other manufacturers. Radio equipment of the present document shall also comply with 
TS 102 361-1 [5]. The payload voice channel procedures specified in clause 6.6.2 closely follow the procedures 
specified in TS 102 361-2 [6]. Similarly the packet data is transported on a payload channel described in clause 6.6.3 
follow the procedure specified in TS 102 361-3 [7]. Where differences exist those differences are stated in the payload 
channel clauses of the present document. 

Slot formats, field definitions, and timing are defined for MS/BS (TS/TSCC) control signalling. The standard can be 
used to implement a wide variety of systems, from small systems with only a few physical radio channels (even single 
physical radio channel systems), through to large networks, which may be formed by the interconnection of BS radio 
sites. 

A description of the TDMA structure is provided followed by the basic slot formats and bit definitions appropriate to 
the trunking protocol. Where procedures are common to the Service and Facilities defined in TS 102 361-2 [6] and 
TS 102 361-3 [7], only the differences are described in the present document. 

The present document does not provide the specification or operational detail for system implementation that include 
but are not limited to network management, vocoder, security, data, subsystems interfaces and data between private and 
public switched telephone networks. It describes only the appropriate access requirements compatible with the Air 
Interface. 

The protocol offers a broad range of user facilities and system options. However, it is not necessary to implement any or 
all of the facilities available; an appropriate subset of the protocol could be implemented, according to the user 
requirements. Also, there is scope for customization for special requirements, and provision has been made for further 
standardized facilities to be added to the protocol in the future. 

The standard defines only the over-air signalling and imposes only minimum constraints on system design. 

Trunked radio systems are characterized by regulating channel access. A logical channel is assigned as a control 
channel (TSCC). The TSCC has an Inbound path for transmissions from MSs (inbound and outbound path for 
transmissions from the Trunked Station (TS) to MSs (outbound channel). Control channel packets generated by a Trunk 
Station Control Channel (TSCC) transmit on the outbound path that all MSs listen to when not involved in a call. MSs 
request access to the system by random access. The system resources are then granted by the Trunk Station Control 
Channel (TSCC). This trunking protocol is designed to minimize the signalling required to provide MSs with a 
particular service in order to provide the greatest possible throughput. 

Trunked radio systems may be characterized by the following possible configurations: 

a) Dedicated Control Channel: 

A Trunk Station Control Channel (TSCC) is transmitted continuously. This channel occupies one DMR 
TDMA channel. MS access is strictly controlled and access is by invitation only. One TSCC can support 
a large number of payload channels. There are a number of tier III services (such as short data 
messaging) that only utilize the TSCC. This mode of operation yields the highest performance and 
throughput. 

b) Composite Control Channel: 

A Trunk Station Control Channel (TSCC) may revert to a payload channel if a payload services is 
requested and no other payload channels are available. When the payload call is completed, the channel 
returns to its control channel function. The ability to have composite control channels is of benefit for TS 
with a very small number of physical radio channels. When the TSCC reverts to a payload function. MS 
who remain idle lose the control channel and cannot access the system and its services until the control 
channel returns. Thus the throughput and performance must be assessed and balanced with the benefits 
of the additional temporary payload channel. The present document does not specify if a TSCC shall 
continuously transmit slots inviting access. 
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c) "Time Share" Control Channel: 



The term "time-shared control channel" refers to a control channel where multiple TS (whether co-sited 
or multi-sited) share one physical radio channel for control purposes by dividing the use of the frequency 
in time, (not to be confused by DMR TDMA). Each TS transmits a burst of control channel activity in 
turn. This mode of operation is complicated in DMR systems because each physical channel is able to 
support two independent TDMA logical channels. The present document does not attempt to solve the 
difficulty. ETSI-DMR does not support time-share control channels. 

d) Asynchronous Access: 

In some radio spectrum, independent users/agencies share frequencies and national administrations 
mandate that when not transporting payload, the TS must de-key and yield use of the channel(s) to the 
co-channel users (i.e. by default, the equipment is de-keyed). Also, there can be no interconnection 
between the independent users/agencies because, they are independent and may not even be co-located at 
a site (independent users/agencies may not wish to coordinate use of the channel). Additionally, some 
co-channel users may just be conventional talk-around users, in which case there is no fixed end 
equipment to coordinate. What may be practical in this scenario is to trade-off (or sacrifice) control 
channel capacity/performance for the ability to support trunking. The present document provides the 
facility for MS to activate a physical TSCC channel whereupon a short burst will regulate and invite 
access. 

4.1 Protocol architecture 

The purpose of this clause is to provide a model where the different functions and processes are identified and allocated 
to different layers in the DMR protocol stack. 

The protocol stack in this clause and all other related clauses describe and specify the interfaces, but these stacks do not 
imply or restrict any implementation. 

The DMR protocol architecture that is defined herein follows the generic layered structure, which is accepted for 
reference description and specification of layered communication architectures. 

The DMR standard defines the protocols for the following three-layered model as shown in figure 4.1. 

The base of the protocol stack is the Physical Layer (PL), which is the layer 1. 

The Data Link Layer (DLL), which is the layer 2, shall handle sharing of the medium by a number of users. At the 
DLL, the protocol stack shall be divided vertically into two parts, the User plane (U-plane), for transporting information 
without addressing capability (e.g. voice or data stream), and the Control plane (C-plane) for signalling with addressing 
capability, as illustrated by figure 4.1. 

The Call Control Layer (CCL), which is layer 3, lies in the C-plane and is responsible for control of the call (addressing, 
facilities), provides the services supported by DMR, and supports the Data Service. U-plane access at layer 2 (DLL) 
supports voice and packet data service, which is available in DMR. The Control Layer and the facilities and services 
offered by Tier III DMR are described in the present document. 
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Control Plane 



User Plane 




Call Control Information 



Intrinsic Services 



Short Data Service 



Packet Data Service 



CALL CONTROL LAYER 



Layer 2 



Voice Pay load 



DATA LINK LAYER 



Layer 1 



PHYSICAL LAYER 



Figure 4.1 : DMR protocol stack 

4.1 .1 Air Interface Physical Layer (layer 1) 

The Air Interface layer 1 shall be the physical interface. It shall deal with the physical burst, composed of bits, which is 
to be sent and/or received. The Physical Layer is described in parti of this multi-part deliverable, see TS 102 361-1 [5]. 

The Air Interface layer 1 contains the following functions: 

• modulation and demodulation; 

• transmitter and receiver switching; 

• RF characteristics; 

• bits and symbol definition; 

• frequency and symbol synchronization; 

• burst building. 

4.1 .2 Air Interface Data Link Layer (layer 2) 

The Air Interface layer 2 handles logical connections and hides the physical medium from the upper layers. The Data 
Link Layer is described in clauses 5 to 9 of TS 102 361-1 [5]. Layer 2 services are described in the present document if 
those services are not already described in TS 102 361-1 [5]. 

The main functions are as follows: 

• channel coding (FEC, CRC); 

• interleaving, de-interleaving and bit ordering; 

• service answer response and retry mechanism; 

• media access control and channel management; 

• framing, superframe building and synchronization; 
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burst and parameter definition; 

link addressing (source and/or destination); 

interfacing of voice applications (vocoder data) with the PL; 

data bearer services; 

exchanging signalling and/or user data with the CCL; 

authentication by challenge and response. 

4.1 .3 Air Interface Call Control Layer (layer 3) 

Air Interface layer 3 (CCL) is applicable only to the C-plane, and shall be an entity for the services and facilities 
supported by DMR on top of the layer 2 functionality. The Call Control Layer for trunking described in the present 
document and may have embedded intrinsic services associated to it. 

The CCL provides the following functions: 

• BS/TS/TSCC activation / deactivation (for asynchronous access mode); 

• establishing, maintaining and terminating of calls; 

• individual or talkgroup call transmission and reception; 

• destination addressing (DMR IDs or gateways as appropriate); 

• support of intrinsic services (emergency signalling, pre-emption, late entry, etc.); 

• data call control; 

• announcement signalling; 

• management of available resources: 

management of a control channel resource by a random access protocol; 
queuing for payload resource; 

• individual or talkgroup call set-up via a dedicated signalling channel; 

• MS location information by registration; 

• MS power save; 

• broadcast of system parameters to radio subscriber terminals. 

4.2 Services and Facilities 

A Tier III system is able to support either a wide range or narrow range of Services and Facilities. Users who select a 
service specified in the present document that is not supported by a particular system shall receive an unambiguous 
refusal of service response. 

The services and facilities defined in the present document may be used for Tier III products and is called the "default 
feature set" which is allocated to the "Standards Feature ID (SFID)". There is a possibility in the DMR standard which 
allows manufacturers to define and implement "private" feature sets which contain additional "private" services and 
facilities, which may possibly not be understood by products not supporting this "private" feature set. In addition, some 
"Standards Feature ID" PDUs may contain optional manufacturer specific information elements. 
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The "standard feature set" contains the following services and facilities: 

a) Generic services: 

1) MS Access control and management using a control channel and a random access protocol; 

2) MS Location within the system radio coverage by radio site identification and registration; 

3) Control Channel hunting; 

4) System acquisition authorization; 

5) A unified data transport mechanism to support the short data service, the supplementary data service and 
destination addressing through gateways; 

6) Broadcast of system parameters to MS; 

7) MS Authentication; 

8) Feature Not Supported; 

b) Primary voice services: 

1) talkgroup call service; 

2) individual call service; 

c) Supplementary voice services: 

1) all call service; 

2) broadcast voice call service; 

3) open voice channel mode call service; 

d) Primary Data Services: 

1) Short Data Service; 

2) Packet Data Service; 

e) Supplementary Service: 

1) Supplementary data transfer service; 

2) MS stun and revive; 

3) MS Kill. 

The description of the services and features use diagrams where necessary to illustrate and highlight specific points both 
on the control channel and pay load channel. 

4.3 Device Addresses 
4.3.1 MS Addresses 

Tier I and Tier II MSs shall be personalized with at least one individual or one talkgroup identity (TS 102 361-2 [6], 
clause C.2.2). Tier III MSs shall be personalized with at least one individual identity and may be a member of one or 
more talkgroups. 



4.3.2 Services and Gateway Addresses 



The Tier III protocol defines additional addresses to identify Services and Gateways in PDUs exchanged between MS 
and TS (TS 102 361-1 [5], annex A). The addresses prescribed in tier III systems are defined in clause A.4. 
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4.4 Conventional/Trunked Systems 

Conventional Tier I and Tier II DMR systems permit MS to control their own channel access (subject to any polite 
protocol). 

Many of the conventional operations such as selection of the physical radio channel is automated by this protocol: 

a) A single site trunked network is characterized by multiple MS communicating with a single location Trunked 
Station (TS); 

b) A wide area trunked network is characterized by multiple MS communicating with a multiplicity of Trunked 
Stations (TS). 

A TS shall be equipped with one or more physical channels. Each TS may be configured with one or two control 
channels(TSCCs). Where two TSCCs are configured, the TSCCs may be arranged in one physical channel or separate 
physical channels. The tier III protocol can separate the population of MS fleets between multiple TSCCs so that there 
is effective load sharing. 

For a fully regulated system, at least one channel shall be configured as a Trunk Station Control Channel (TSCC) for 
MS management, signalling, and broadcast of system parameters. MS access is strictly controlled on the TSCC. 

An unregulated asynchronous system shall permit MS access subject to polite rules. 

4.5 MS Location 

As MS travel around a wide area network they may be within range of a number of different Trunked Stations (TSs). 
Registration is a method by which the system can determine which radio site or group of radio sites MSs are located 
within a wide area network. This information avoids searching for MSs throughout the whole network, consequently 
reducing call set-up time and control channel loading. 

Registration may also be employed by a Single Site system to determine when MSs are active and able to receive calls. 

A secondary application of the registration process is that it enables power save parameters to be passed between MS 
and the system. 

If an MS is switched off or is subjected to a user selected change of network, the MS may attempt to de-register. The 
MS makes a de-registration random access to the TSCC on a "best endeavours" basis. If the procedure is not completed 
within a short time window (T_dereg) the process is abandoned. 

4.6 Tier III Services 

A DMR TS can allocate resources for a range of services including individual call, talkgroup call, line connected call, 
and a selection of data services. 

Calls to talkgroups may be restricted by the Network to a single radio site or connected to a multiplicity of radio sites. 
The particular sites involved in the call may be defined by the Network using manual configuration or automatic 
selection. 

Supplementary data may be sent between MS and the network during the call set-up phase using the Supplementary 
Data Transfer Service to poll for, or deliver additional information using a Unified Data Transport method. Examples 
include: 

a) the inbound transport of dialling digits for calls to the PSTN, PABX extensions or dotted addresses for IP 
gateways; 

b) the transport of MS location information using data collected from lEC 61 162-1 [8] compatible devices; 

c) the transport of any supplementary user data; 

d) the outbound transport of CLI information for calls from PSTN and PABX gateways to the called MS(s); 

e) the outbound transport of an IP address to called MS. 
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4.6.1 MS initiating calls 

A MS may initiate a call to any of the following called parties: 

a) an individual MS; 

b) a line-connected terminal device including a PABX extension or PSTN destination; 

c) a talkgroup, or all MSs in the system. 

The system shall send a refusal of service response to any calls that request inappropriate Services and Facilities for a 
particular destination address. 

Some services may be addressed to the TS itself. 

During the call set-up phase, the TSCC may pass information back to the caller, to indicate the progress of the call. For 
example, it shall indicate the reason for any delays in call set-up or the reason for a call failure. 

4.6.2 MS receiving calls 

A MS may receive calls from a MS or line connected terminal device (such a device may be a PABX extension or the 
PSTN). 

In addition, some PDUs may originate from the TS itself. 

For a call from an MS, the calling address shall be supplied to the called unit. For a call from certain line connected 
gateways such as a PABX extension or from the PSTN, the protocol enables Source Address information to be carried 
to the MS. (An example is CLI information from a PABX extension or the PSTN). 

Incoming calls may be addressed to the MS individually or to a talkgroup. 

4.6.2.1 MS receiving individual calls 

A MS may refuse to accept all incoming calls, for example by means of a "will call-back" control, or incoming calls 
could be refused selectively, depending on the source of the call. If an MS user does not wish to proceed with an 
incoming call immediately, the user can indicate that the call will be returned. If a MS user does not wish to receive any 
incoming calls, the calls may be rejected completely. 

Systems may be configured to alert a called individual and require the user to indicate that he is ready, before a payload 
channel is allocated for a call (full off air call set-up). This feature is not available for this release of the document. 

4.6.2.2 MS receiving calls to talkgroups 

A MS may be a member of an arbitrary number of talkgroups. 

An MS may be configured such that it may selectively accept or ignore a call to one if its talkgroup memberships An 
MS may also be configured to ignore a call to one of its talkgroup memberships if it is waiting for an individual call. 

4.7 Physical Link Organization 

This protocol makes use of the physical layer 1 prescribed in TS 102 361-1 [5] DMR Air Interface protocol. 

4.7.1 Radio Frequency Allocation 

The Tier III protocol supports a number of different physical channel strategies to accommodate operation in radio 
channels that may be dedicated, in blocks or re-farmed. 
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Physical radio channels may be specified by either: 

a) a logical channel plan whereby a transmitter and receiver frequency is mapped to a logical channel number. 
The tier III protocol permits up to 4 094 such logical / physical relationships; and/or 

b) a mechanism whereby the absolute transmitter and receiver frequencies are specified in the PDUs that are 
passed between BS and MS at the air interface. 

4.7.2 Colour Code (CC) 

A Colour Code (CC) is present in the Embedded Signalling Field (EMB) and general data burst to provide a simple 
means of distinguishing overlapping sites, in order to detect co-channel interference. Tier III systems assign the 
physical channels automatically therefore the MS and TS must know and be in agreement which colour code is 
allocated for each physical channel. The following strategy is employed in tier III systems: 

a) The default colour code is OOOO2. If a colour code has not been specifically assigned, or transmitted on the 
TSCC in an extended Channel Grant or extended Move PDU, the colour code shall be set to the default; 

b) In tier III systems MS shall be polite to own colour code; 

c) MS may maintain a list of logical channel numbers and their corresponding colour code assignments (see 
annex C). 



4.8 



DMR TDMA burst and channel structure 



The described solution is based on the 2-slot TDMA structure described in TS 102 361-1 [5] clause 4.2. 
The logical channels are separated into two categories: 

• a control channel carrying signalling; and 

• payload channels carrying speech or data information. 

Generally MSs operate in half duplex mode using aligned channel timing (see TS 102 361-1 [5], clause 5.1.1) but full 
duplex is possible for calls to line connected terminals using Offset TDMA timing (see TS 102 361-1 [5], 
clause 5.1.1.2) by allowing a MS to transmit in one time slot and receive the fixed end transmission on the alternate 
time slot. MS that are directed to a physical channel using offset timing shall be notified by an identifier transmitted to 
the MS(s) during the call set-up. 

A generalized diagram of exchanges between the TSCC and MS is shown in figure 4.2 where the slots for the two 
TDMA physical channels are shown. 
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Figure 4.2: Key points for a Tier III TSCC 

Key points particular to Tier III trunking illustrated by figure 4.2 include the following: 

• While the TSCC is keyed up, the two outbound logical channels are continuously transmitted, even if there is 
no information to send. If either of the logical channels are configured as a control channel, and that control 
channel is idle, information is constantly transmitted to manage MS access and broadcast parameters to MSs. 
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• The channel 1 and 2 bursts in the inbound channel are offset 30 ms in time from the channel 1 and 2 bursts in 
the outbound channel. This number scheme allows a single channel identifier field in the outbound CACH to 
use the same channel number when referring to the inbound and outbound channels. 

• Differing SYNC patterns are used in voice bursts and data bursts to allow the receiver to differentiate between 
them. Different SYNC patterns are used for inbound and outbound channels to help the receiver reject 
co-channel interference. 

• A physical channel that carries a TSCC shall use aligned timing as prescribed in clause 5.1.1.1 of 

TS 102 361-1 [5]. Two independent control channels or one control channel + one payload channel may be 
configured. A TSCC may temporarily revert to a payload channel. 

• Referring to figure 4.2, a random access burst on the inbound channel labelled "A" shall be acknowledged by a 
PDU on the outbound channel. This acknowledgement may be transmitted in slot "B", although the protocol is 
able to postpone the acknowledgement to allow for computational or network delays. 

• For a MS response to a PDU received from the TSCC, the MS shall transmit its PDU in the timeslot but one 
following the end of the TSCC PDU. I.e. a PDU from the TSCC in slot "C" that requires a response from a MS 
shall be acknowledged on the TSCC in slot "D". 

• The MS response at "D" cannot collide with another random access burst because the slot is protected by 
setting the AT bit is the CACH to busy. MS must test this bit before making a random access attempt. Random 
access is not permitted if AT=1. 

• The outbound channel defines a CACH channel between TDMA bursts that manages the framing and channel 
access of the logical channels and provides a low speed channel for signalling. CACH framing bits are 
defined, allowing the low speed channel to support a range of PDU sizes. 

4.9 Introduction to the TS Structure 

These clauses outline some key aspects of the Tier III protocol by reference to examples. The Tier III protocol manages 
MS access and Service provision by means of a TSCC (control channel). MSs request Service by means of random 
access. The tier III protocol provides a wide variety of configurations to match the requirements of dedicated and shared 
radio spectrum. The TSCC outbound channel may be: 

a) continuously transmitting slots that invite MS access, broadcast of system parameters to, and managing the 
resources that are available to MS; 

b) transmitting information as a) but reverting to a payload channel when other payload channels are not 
available; 

c) de-keyed until activated by an MS burst when used in shared spectrum. 



4.9.1 An individual voice call example 



Two MS, MS(A) and MS(B) are active listening to the TSCC. MS(A) requests a voice service to MS(B). Before a 
payload channel is assigned on the TSCC, the system checks that the MS(B) is in radio contact and wishes to accept the 
call. If MS(B) sends a positive acknowledgement response (indicating that MS(B) will accept the call), the system 
allocates a payload channel for the call. 
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Figure 4.3: Individual Call Set-up example 

Referring to figure 4.3, some key aspects are described: 

a) TDMA Channel 2 is assigned as a TSCC. TDMA Channel 1 is idle. 

b) When a TSCC has no calls in progress, it will transmit system management or system broadcast PDUs to all 
MSs listening to the TSCC. MSs may listen to TDMA Channel 1 for the purposes of error rate measurement 
but they shall not make use of any information from those PDUs. 

c) MS(A) makes a Service Request at point "A" using aligned timing (see TS 102 361-1 [5], clause 5.1.1.1). 

d) The TSCC sends an AHOY PDU (point "B") addressed to MS(B) that requires an acknowledgement response. 

e) MS(B) responds with an acknowledgement at point "C". 

f) At point "D", the TSCC sends a Channel Grant PDU addressed to MS(A) and MS(B). A logical channel 
information element in the Channel Grant PDU directs the MSs to a particular physical and logical channel. 
The Channel Grant PDU is not acknowledged so the PDU is repeated for reliability at "E". A TSCC may 
transmit the repeated Channel Grant PDUs consecutively, or wait for a few slots before repeating the Channel 
Grant. 

g) In this particular example the TSCC has chosen to allocate the logical Channel 1 of this physical channel for 
the call. Logical Channel 1 therefore changes from idle to payload immediately after the TSCC transmits the 
first Channel Grant PDU. 

h) Since each TDMA burst takes 30 ms, the best case performance for a Tier III individual call set-up is 210 ms. 

4.9.2 A talkgroup call example 

For a talkgroup call, the intermediate step of checking if MS(B) is in radio contact is not required so the best case 
performance for a Tier III talkgroup call is 90 ms. 
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Figure 4.4: Talkgroup Call set-up example 

Figure 4.4 illustrates a call set-up for a talkgroup. MS(B) is a party to that talkgroup. For a talkgroup call, the 
intermediate step of checking if MS(B) is in radio contact is not required so the best case performance for a Tier III 
talkgroup call set-up is 90 ms. 

In this particular example the TSCC chooses a separate physical radio channel for the call. The particular physical and 
logical TDMA channel information elements are carried in the Channel Grant PDUs. The Channel Grant PDUs are 
repeated for reliability. 

Key protocol aspects are: 

a) When both payload channels are idle, no radio transmission is necessary. 

b) When at least one payload channel is assigned the transmitter is activated and one logical channel carries the 
payload for the call. The other logical channel remains idle. 

c) Although in this example the clocks and bursts in the payload channel are time aligned with the TSCC, there is 
no requirement to do so. 

4.10 Network architecture 

The DMR trunked protocol is defined in terms of the Services and Facilities. It is defined to ensure interoperability with 
DMR MSs. The Tier III structure relies on the Air Interface TS 102 361-1 [5]. 

The gateways to Public Switched Telecommunication Network (PSTN), and other non Air-Interface gateways are not 
defined within the present document. They are shown only for informative purposes. 

A Trunked Station (TS) consists of one or more physical radio channels (BS), each physical channel supporting two 
TDMA logical channels. Either or both logical channels of a BS may carry a TSCC. All of the clocks of the BS making 
up a TS may be derived from a common reference standard so that the framing structure is synchronized across all BS 
within a TS. 
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4.10.1 Network functions 



In addition to the normal call handling functions required to provide the telecommunication services identified above, a 
number of standard network procedures are needed for the efficient operation of the system and to provide an 
acceptable grade of service to the users. 

4.10.1.1 Establishing service 

A notable feature of a Tier III trunked system is that physical channel acquisition is performed automatically when a 
MS is powered up. The user does not need to manually select physical channels. The relevant physical channel is stored 
in the MS or a search is performed to find an applicable TSCC. If the MS is directed to a payload physical channel on 
the TSCC, the applicable payload channel is transmitted to the MS by a Channel Grant PDU that specifies the physical 
and logical channel. 

4.10.1.2 Network Identifier 

All TS carry a network and radio site identifier. This identifier, the System Identity Code (C_S YScode) is transmitted 
frequently by a TSCC. The C_SYScode is carried in CSBK signalling packets and also embedded in the CACH. The 
C_S YScode is composed of MODEL, NET, SITE and PAR information elements. Within a particular network, the 
MODEL and NET remains a constant. Each TS is designated a different SITE parameter. MSs use the MODEL and 
NET to determine if they are authorized to attempt to become active on that network. 



4.10.2 MS Location by Registration 



The coverage area of a Tier III trunked network is divided into a number of Location Areas (DMRLAs). A DMRLA 
corresponds to a single radio site or a small number of radio sites structured as a DMRLAs. 

Implicit registration is the network functionality that registers the location of the MS without need for an explicit 
registration PDU. Implicit registration can be attained by any system PDU that conveys the MS individual identity, 
e.g. call request, service answer response. 

It is possible that due to adverse conditions the registration information held by the network and that held by the MS 
may not be the same. To restore and maintain the registration records: 

a) The system shall update its registration records from MS random access call requests (The network may 
however deny the service requested by the MS for other reasons). 

b) Responses from MS (resulting from a radio check for example) implicitly update the system registration 
records. 



4.11 Trunking methods 



DMR Tier III systems are able to implement the "message trunking", "transmission trunking" or "quasi-transmission" 
trunked methods. 



4.1 1 .1 Message trunking 



Message trunking is a payload channel allocation strategy in which the same payload channel is continuously allocated 
for the duration of a call, which may include several separate call items or transactions (i.e. PTT activation by separate 
terminals). The payload channel is only de-allocated when the call is explicitly cleared by the call owner in the case of a 
talkgroup call, either party hanging up during an individual call or if an activity timer expires. The BS may also clear 
the call at any time but the BS must be confident that all parties in the call hear the PDU to clear down the call. 

Once a payload channel has been allocated the users will experience the minimum delay for each transmission item 
since there is no queuing for the allocation of channel resources. The absence of any perceptible delay when the PTT is 
activated ensures that a conversation can proceed without interruption. This strategy is likely to minimize the processing 
and signalling overheads in the network infrastructure. 

The disadvantage of this strategy is that the channel remains allocated even when there may be significant gaps in the 
PTT items and this may result in less efficient use of the available channel capacity. 
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4.1 1 .2 Transmission trunking 

A payload channel is allocated for each PTT item. When the user releases the PTT, the payload channel is de-allocated 
down and the MS returns to the control channel. The following PTT is allocated a new payload channel. 

Users may experience a delay for each transmission item particularly when the system is busy because a payload 
channel may not be immediately available. In this case the system must queue the MS until a payload resource becomes 
available. An indication may be provided to the user that the payload channel is allocated for the speech item. 

4.11.3 Quasi-Transmission trunking 

A payload channel is allocated to the called and calling parties at the start of the call. When the user releases the PTT, a 
short hang-timer holds the payload channel to permit the other party to speak. If the hang-timer expires the payload 
channel is de-allocated and the next PTT item sets up a new call. This method overcomes the delay in transmission 
trunking but users experience different effects depending on the possible expiry of the hang-timer. 



Trunking Control Channel Formats 



A TS shall employ a minimum of one physical channel partitioned in time into TDMA frames and timeslots as defined 
in TS 102 361-1 [5], clause 4.2. At least one of the TDMA channels shall carry control channel signalling. When idle, 
MSs shall monitor the Trunk Station Control Channel (TSCC) outbound channel. This protocol permits one additional 
TSCC to be employed in a TS to share the load. 

The following SYNC patterns shall be deployed (see TS 102 361-1 [5], clause 9.1.1 for details and bit patterns for the 
frame SYNC): 



For the TS outbound channel 



BS sourced data. 



For the MS inbound channel 



MS sourced data. 



Signalling on the TSCC outbound channel is nominally continuous, with each TDMA Frame comprising two 
independent logical channels. The channel consists of two TDMA traffic channels (channels 1 and 2) as well as a 
CACH for channel numbering, channel access, system identification and power save. 
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Figure 5.1 : Slots and Frames 

Figure 5.1 illustrates slots, TDMA frames, random-access-frames and power-save-frames. 

A slot is the elementary DMR burst described in TS 102 361-1 [5]. 

A TDMA-frame encompasses two continuous time slots 1 and 2 or 2 and 1 . 

A power-save-frame is defined by transmission of four consecutive Short LC PDUs embedded in the CACH. A power- 
save-frame is transmitted by a TSCC every 480 ms. 
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5.1 



The use of the CACH 



The Short LC contains 3 octets of data associated with the SYS_Parms Short Link Control (Opcode - OOIO2) 
(see TS 102 361-1 [5], clause 7.1.4). Tier III systems that have any one of the logical channels configured as a TSCC 
shall continuously or periodically transmit the S YS_Parms Short Link Control to broadcast a sub-set of the System 
Identity Code, the Reg information element and a Common_Slot_Counter. All information carried by the Short Link 
Control is common to both logical channels. 

Since the entire Short LC payload can be delivered in 4 CACH bursts, one SLCO can be sent by the CACH every 
4x30ms= 120 ms. 

NOTE: The Tier III protocol makes use of the AT bit transmitted in the CACH as key elements in the random 
access protocol described in clause 6.2. 

5.1.1 SYS_Parms - System Identity Code Subset 

The full C_Syscode information element is length 16 bits. Only the most significant 14 bits of the C_SYScode are 
carried in the CACH because the CACH is common to the two logical channels. One physical channel may carry one or 
two TSCCs. Each TSCC is identified by the two bit PAR information element that is conveyed in the two Least 
Significant Bits (LSBs) of the C_SYScode. 

The CACH is common to both logical channels so the PAR field cannot be specified in the CACH. Not all CSBKs on 
the outbound channel contain the SYScode. If a MS is searching for a control channel and trying to determine if it is 
permitted access, it may disregard a sampled channel by decoding the CACH. If there is no match then the MS does not 
need to stay looking for a CSBK that contains the C_Syscode. 

5.1.2 SYS_Parms - Reg 

The Reg information element carries a flag that specifies if this particular system requires MS to register before 
becoming active. The Reg is also carried in the Aloha CSBK PDU. 

5.1 .3 SYS_Parms - Common_Slot_Counter 

The Common_Slot_Counter is broadcast by the S YS_Parms and represents a positive integer in the range to 5 1 1 . The 
counter is incremented in each successive SYS_Parms Short Link Control PDU. When the counter is incremented from 
51 1 it rolls over to 0. The Common_Slot_Counter therefore increments every 120 ms. 
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Figure 5.2: Common Slot Counter 

Figure 5.2 shows how the Common Slot Counter is broadcast in the CACH. The Common_Slot_Counter is read by MS 
wishing to synchronize power save periodic sleep cycles (see clause 6.4.7). 
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5.2 Tier III signalling 



The tier III protocol makes use of the single block CSBK and Multiple Block Control signalling packet structure 
described in TS 102 361-1 [5], clause 7.2. PDUs addressed to an individual MS or a talkgroup shall contain the Source 
Address. The Tier III protocol also uses the Unconfirmed Data type for the Unified Data Transport mechanism. UDT 
blocks consist of a header and a number of intermediate blocks contiguously transmitted. The UDT transmits the UDT 
header followed by one to four appended data (UDT intermediate blocks) to transport variable length system or user 
data between entities. 

5.3 Modes of control channel 

TSCCs may be dedicated, composite or asynchronous. A dedicated TSCC never reverts to a payload channel whereas a 
composite TSCC may change its mode and carry payload if all other payload channels within a particular TS are busy. 

5.3.1 Dedicated TSCC 

A dedicated TSCC is generally employed in a TS where a large number of BS (hence payload channels) are employed. 
The advantages of a dedicated TSCC are: 

a) The TSCC is always available for MS who are hunting for a appropriate and valid service; 

b) The TSCC is always available to process secondary services such as MS location (registration), short data 
calls, etc.; 

c) The TSCC is always available to accept random access requests and queue such requests if resource is not 
immediately available; 

d) The TSCC can broadcast information to MSs more frequently as the TSCC function is not interrupted. 

5.3.2 Non-Dedicated TSCC 

A composite TSCC may suspend its control channel function and revert to a payload mode. This is suitable for TSs that 
are equipped with a very small number of payload channels and the traffic expected exceeds the capacity of those 
channels. The control channel reversion provides one additional payload resource. However, the shortcoming is: 

a) MS who are hunting for a appropriate and valid service may sample the physical channel when it has reverted 
to payload and therefore skip the channel; 

b) The TSCC is not available to process secondary services such as MS location (registration), short data calls, 
etc.; 

c) The TSCC cannot accept random access requests. The control channel interruption will most likely cause the 
MS not involved in the call to hunt; 

d) MS that return from a payload channel expecting the TSCC to be present will see a payload channel and 
therefore hunt for a new control channel. 



5.3.3 Operation in shared spectrum 



Clause 4d) describes an asynchronous access. In this mode the TSCC remains inactive (in fact the physical channel 
remains de-keyed) until a MS activates the TSCC with a short burst. The MS then synchronizes to the forward control 
channel before making its random access service request. 
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5.4 



CSBK/MBC/UDT Block Structure 



CSBK/MBC/UDT PDUs may be sent by a TS on the outbound channel and MS on the inbound channel. In some 
instances it is necessary to send more information than can be accommodated in a single block CSBK PDU. In those 
cases multi-block PDUs of type MBC or UDT are transmitted. Multi-block PDUs shall use the following Data Type 
information elements, (see TS 102 361-1 [5], clause 6.2): 

a) For PDUs except UDT, MBC Header and MBC Continuation are used; 

b) PDUs of type Data Header and Unconfirmed Data Continuation are used to transport information on the 
outbound channel and inbound channel for the Unified Data Transport (UDT) mechanism. 

5.4.1 CSBK/MBC/UDT PDUs on the TSCC outbound channel 

The PDUs sent by a TSCC on the outbound channel are classified as shown in figure 5.3. 
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Figure 5.3: TSCC CSBK/MBC/UDT Outbound channel Structure 
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Table 5.1 : TSCC CSBK/MBC/UDT Outbound channel PDUs 



Class 


Mnemonic 


PDU Descriptor 


Description 


Broadcast 


C GRANT 


- Channel Grant 


Transfer a call to the payload channel 


C_MOVE 


- Move to a new physical channel 


MSs shall move to an alternative 
TSCC 


C ALOHA 


- Aloha 


To Manage Random Access 


C_BCAST 


- Announcements 


PDUs intended for all MSs listening to 
this TSCC 


Ahoys 


C_AHOY 


- Ahoy 


Sent to an individually addressed MS 
and demand a response 


Acknowledgements 


C_xACKD 


- Acknowledgements 


A response to PDUs from the MS that 
demand a response: 

C ACKD, C NACKD, 

C WACKD.C QACKD 


Unified Data 
Transport Outbound 


C_UDTHD 


Short System Message 
Outbound (see note) 


System PDU addressed to an 
individually addressed MS and 
demand a response 


Short Data Message Outbound 
(see note) 


Short data message addressed to an 
individual MS or talkgroup 


NOTE: C_UDTHD PDUs are made up of multiple blocks that consist of a UDT Header followed by 1 to 4 
appended UDT data blocks - see annex B. 



5.4.2 CSBK/MBC/UDT PDUs on the TSCC inbound channel 

The PDUs sent by a MS on the TSCC inbound channel are classified as shown in figure 5.4. 



SLOT 



Random Access 



Ackvitation 



Acknowledgements 



Unified Data 

Transport 

Upload 



Individual Serv 



Talkgroup Szr\/ 



Secondary Szr\/ 



Auth Challenge 



C_ACK 



C_NACK 



Auth Response 




Short System Data 



Short Data N^zssaqz 



Uplink Ext Addr 



Uplink Dial Dig 



Uplink Data 



Individual 



Talkgroup 



All Call 



Figure 5.4: TSCC CSBK/MBC/UDT Inbound channel structure 
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Table 5.2: TSCC CSBK/MBC Inbound channel PDUs 



Class 


Mnemonic 




PDU Descriptor 


Description 


Random 
Access 


C_RAND 


- 


Random Access 


Random Access Requests 


Ackvitation 


C_ACVIT 


- 


Ackvitation 


A response to PDUs that invite a 
further response 


Acknowledgements 


C_xACKU 


- 


Acknowledgements 


A response to PDUs from the TSCC 
that demand a response C ACKU, 
C NACKU 


Unified Data 
Transport Inbound 


C_UDTHU 


- 


Short System Message Inbound 


System PDU addressed to an 
individually addressed MS or the 
TSCC as a response to an Ahoy PDU 
from the TSCC 


- 


Short Data Message Inbound 


Short Data Message addressed to an 
individually addressed MS or the 
TSCC as a response to an Ahoy PDU 
from the TSCC 



5.4.3 CSBK/MBC PDUs on the Payload Channel Outbound channel 

The PDUs sent by a TSCC on the outbound channel are classified as shown in figure 5.5. 
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Figure 5.5: Payload CSBK Outbound channel Structure 
Table 5.3: Payload CSBK Outbound channel PDUs 



Class 


Mnemonic 


PDU Descriptor 


Description 


Broadcast 


P_GRANT 


- Channel Grant (see note) 


Swap a call to a new payload 
channel 


P_CLEAR 


- Payload Channel Clear 


Clear the call from the payload 
channel 


P PROTECT 


Channel Protection 


Access control 


Ahoys 


P_AHOY 


- Ahoy 


Sent to an individually addressed MS 
and demand a response 


Acknowledgements 


P_xACKD 


- Acknowledgements 


A response to PDUs from the MS 
that demand a response P ACKD, 
P_NACKD, P_WACKD.P_QACKD 


NOTE: A Channel Grant PDU is transmitted by the TS on a payload channel to swap an ongoing call to a new 
payload channel. 
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5.4.4 CSBK PDUs on the Payload Channel Inbound channel 

The PDUs sent by a MS on the Payload Channel inbound channel are classified as shown in figure 5.6. 
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Figure 5.6: Payload CSBK Inbound channel Structure 
Table 5.4: Payload CSBK Inbound channel PDUs 



Class 


Mnemonic 




PDU Descriptor 


Description 


Random 
Access 


P_RAND 


- 


Random Access 


Random Access Requests 


Acknowledgements 


P_xACKU 


- 


Acknowledgements 


A response to PDUs from the TS that 
demand a response P ACKU, 
P NACKU 


Maintenance 


P MAINT 


- 


Call Maintenance PDUs 


Disconnect 



Trunking Procedures 



6.1 



Basic Structure 



6.1.1 Channel Structure 



6.1.1.1 



Fully Regulated Structure 



MS require a TSCC to regulate channel access. Therefore a TS shall incorporate one channel that is configured as a 
TSCC. A TS may support one additional TSCC within this protocol. 

The TSCC shall provide the following facilities: 

a) Management and control of channel access by MS using a random backoff mechanism; 

b) Processing service requests to and from MS and optionally to and from line connected entities; 

c) Allocating payload resources to calls; 

d) Broadcast of system information to MS ; 

e) MS location management by registration; 

f) Provision of supplementary services such as short data polling and transfer. 
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6.1 .1 .2 Shared Channel Unregulated Structure 

MS access the channel for services using the basic channel access rules prescribed in TS 102 361-1 [5], clause 5.2.1. 
MS shall be permitted to transmit asynchronous "BS activation" signalling to the TS in accordance with the "BS 
activation" feature (described in TS 102 361-2 [6]). On becoming activated, the TS shall commence transmitting TSCC 
activity on the outbound channel, and the MS shall derive slot timing from this activity. When activated, the TSCC shall 
transmit PDUs inviting random access. 

For Tier III, the outbound channel shall activate one TDMA channel as a TSCC and shall transmit Aloha and/or 
Broadcast PDUs in accordance with the random access procedures specified in the present document. 

The TS shall maintain the timer T_BS_Inactive for each active inbound channel. The T_BS_Inactive timer runs when 
there is no activity on the inbound channel. If the T_BS_Inactive timer expires the TS shall transition to the Hibernating 
state in accordance with in TS 102 361-2 [6], clause G.2.1. Here the TS shall cease transmitting, which deactivates the 
outbound channel. 



6.1 .2 Physical Channel Addressing 



The Tier III protocol supports a number of different physical channel strategies to accommodate operation in radio 
channels that may be dedicated, in blocks or allocated on an ad-hoc basis by an external agency. Physical radio channels 
may be specified by either: 

a) a logical channel plan whereby a transmitter and receiver frequency is mapped to a CHAN information 
elements. CHAN information elements permit up to 4 094 such logical / physical relationships; and/or 

b) a mechanism whereby the absolute transmitter and receiver frequencies are specified in the information 
elements of PDUs that are passed between DMR entities at the air interface. 

For b) there will be a degradation in performance over a) because the information that must be passed between entities 
is greater. However new physical / logical relationships that adds to or modifies the existing channel plan stored in MS 
may be broadcast on the TSCC. 

Annex C provides an illustration how the logical channels may be mapped to physical frequencies. 



6.1 .3 Sub-Division of the MS population 



Certain PDUs transmitted on the TSCC may be directed to and applicable only to a sub-set of the MS population. 
Examples are Aloha (C_ALOHA) PDUs and Broadcast (C_BCAST) PDUs. Applicable PDUs contain a 24 bit address 
information elements and a 5 bit (Mask) number information element. The sub-set division is achieved by using the 
address qualifier (Mask) from the PDU. This parameter instructs a MS to compare the "Mask" least significant bits of 
its individual address with the "Mask" least significant bits of the address field from the PDU (containing the MASK) to 
determine if that PDU is applicable. 

A MS shall note the population subdivision contained in each applicable PDU that it receives. For Mask = to 24, the 
PDU is applicable to the unit if the "Mask" least significant bits of the Aloha address match the "Mask" least significant 
bits of its individual address. 

In this way, the MS population is effectively divided into 2^^^^subsets: 

• If Mask = then no address bits are compared, so there is no subdivision. 

• If Mask = 1 then only MS whose least significant individual address bit matches the least significant individual 
address bit from the PDU received shall consider the PDU to be applicable to that particular MS. 

This process continues up to Mask = 24. In this case the PDU is only applicable to one MS. 
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TSCC Outbound 
























Applicable Message 






Individual Address 
0000 0000 0010 1010 0001 IOOI2 




Address Mask 








1 24 bits 1 5 bits 










^^^ 


— ' — ' — — 




N\S 




^ ' 
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|0|0|0 















Figure 6.1 : Example of PDU containing the "Mask" information element 

Figure 6.1 illustrates a MS personalized with the address 0000 0000 0010 1010 0001 IOOI2. 

A PDU is received that contains a Mask information element. The MS shall therefore determine if that PDU is 
applicable or the PDU shall be discarded. 

EXAMPLE 1 : The Mask information element contains the value OIOO2. 

The value of the Mask is 4 therefore the MS compares the 4 least significant bits of the address information 
element in the PDU received with the 4 least significant bits of the MS individual address. 



MS Indiv' Address 



000000000010101000001001 



Message Received 



00000000001010100001 1001 



Figure 6.2: Applicable PDU defined by Address and Mask 

The least significant 4 bits are compared as shown in figure 6.2. In this case the bits match so this IS an 
applicable PDU for this particular MS. (If Mask were any value from to 4 the PDU would still be 
applicable.) 



EXAMPLE 2: 



The Mask information element contains the value OIOI2. 



The value of the Mask is 5 therefore the MS compares the 5 least significant bits of the address information 
element in the PDU received with the 5 least significant bits of the MS individual address. 

The least significant 5 bits are compared as shown in figure 6.3. In this case the bits do NOT match so this 
PDU shall be discarded by this particular MS. (If Mask were any value from 5 to 24 the PDU would still be 
discarded). 



MS Indiv' Address 
Message Received 



JI 



000000000010101000001001 



X 



000000000010101000 11001 



ni 



Figure 6.3: Non-Applicable PDU defined by Address and Mask 



6.2 



Random Access Procedures 



These clauses define the random access protocol, which is based on slotted aloha that is used to: 

• control the collision of simultaneous random access attempts from different MSs; 

• manage the TSCC to minimize access delays; 
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• ensure system stability; and 

• maintain optimum throughput under heavy traffic loads. 



Random access is the only access method permitted for MS on a fully regulated TSCC. For a tier III system employing 
asynchronous access, and when the TSCC is de-keyed, the first random access attempt shall activate the physical TSCC 
channel whereupon the outbound burst shall regulate further signalling. 

6.2.1 The Random Access Principle 

The figures in the random access procedure clauses adopt the conventions illustrated in figure 6.4. 



' ' slot available for random access 

l ^gggg^ Slot withdrawn, random access not permitted 



I I 



PDU transmitted by a MS on the inbound 
channel 



PDU containing the back-off parameter 'N' 
on the outbound channel 

PDU that requires a response, i.e withdraw 
next TDMS frame (next but one slot) 



Figure 6.4: Conventions used in the figures 

In addition, the TDMA-slot and TDMA-Frame is illustrated in figure 5.1. 

PDUs transmitted on the TSCC on the outbound channel are divided between those that invite random access (such as 
Alohas) and those that withdraw one or more slots for the purpose of soliciting responses from MSs on the inbound 
channel (see clause 6.2.1.1.3). 

6.2.1 .1 Random Access Control 

The TSCC outbound channel creates an environment where TSCC access may be managed and controlled. This 
protocol specifies a specific C_ALOHA PDU that contains the information elements Random-Backoff, Mask, and 
Service Function, to manage and control random access. Other PDUs transmitted on the TSCC also contain the random 
backoff information element. 

All MS initiated services are by random access. If an MS wishes to make a random access attempt, the MS may send 
the random access service request PDU so long as: 

a) access is not inhibited by Mask (see clause 6.2.1.1.1); or 

b) access is not inhibited by the Service Function (see clause 6.2.1.1.2); or 

c) the slot chosen is not withdrawn (see clause 6.2.1.1.3). 

6.2.1 .1 .1 Sub dividing the IVIS population 

C_ALOHA PDUs contain an address information element and a Mask information element. The procedure described in 
clause 6.1.3 is therefore applied. 

A MS shall note the population subdivision contained in each Aloha PDU that it receives. When attempting random 
access, the MS shall check if the population subdivision is applicable to it using the qualifier (Mask) and the address 
field from the Aloha PDU. For Mask = to 24, the PDU is appHcable to the MS if the "Mask" least significant bits of 
the Aloha address match the "Mask" least significant bits of its individual address. 

The subdivision is applied to subsequent TDMA frames marked PDUs that do not contain the Mask information 
element, until updated or changed by the next Aloha PDU. 

In this way, the MS population is effectively divided into 2^^^^ subsets: 

• If Mask = then no address bits are compared, so there is no subdivision (under normal traffic loading, this 
will usually be the case). 

• If Mask = 1 then only units whose least significant individual address bit matches the Aloha address may send 
non-emergency random access PDUs. Thus the MS population has been divided into two subsets. 
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• This process continues up to Mask = 24. In this case only one MS shall be permitted to make a random access 
attempt, (unless the MS requested an emergency service whereupon the MS may make a random access 
attempt for all values of Mask except Mask = 24). 

When a MS becomes active on a TSCC, including when returning from a payload channel, it shall either assume that 
the population is not subdivided (i.e. that the last C_ALOHA PDU was applicable to all MSs) or wait for a C_ALOHA 
PDU before attempting random access. 

6.2.1 .1 .2 Checking the Service-Function 

For service requests except emergency: 

• A MS shall use the Service Function from the C_ALOHA PDU. A MS shall not choose a slot for random 
access unless the random access attempt is for a service type invited by the Service Function information 
element. 

Table 6.1 : Service-Function 



Value 


Remark 


OO2 


Random Access invited for all Services 


OI2 


Random Access Invited for Services that require a 

physical payload channel 

Random Access Invited for registration requests 


IO2 


Random Access Invited for Services that do not 

require a physical payload channel 

Random Access Invited for registration requests 


II2 


Random Access invited for random access 
registration requests only 



• The Service function shall apply until the Service-Function is updated by a subsequent C_ALOHA PDU. 
For emergency service requests the MS is not required to check the Service-Function. 



6.2.1.1.3 



Withdrawing slots from Random-Access 



The TSCC may transmit a PDU (consisting of single block CSBK, multi block MBCs or multi-block UDTs) on the 
outbound channel that solicits a response from a specified MS. The MS response shall be sent in the next TDM A-frame 
following the last block of the TSCC PDU. In order to prevent a collision occurring between this solicited response and 
a random access transmission, the TSCC withdraws this timeslot, thereby prohibiting any random access transmissions 
in the given timeslot. The protocol makes use of the AT bit transmitted in the CACH to indicate to all MS that the 
following slot is withdrawn (see TS 102 361-1 [5], clause 4.5). (This, therefore implies that an MS intending to transmit 
a PDU by random access in a given timeslot shall successfully decode the appropriate CACH and note the value of the 
AT bit to ensure that the chosen timeslot has not been withdrawn from random access.) 

In the following example in figure 6.5, when the TSCC transmits a PDU that requires a response, that PDU withdraws 
the following TDM A frame (slot but one). 



TSCC 
Outbound 



MS 
Inbound 



PDU inviting random access 



Message requires a 
response from MSCB) 



Message that requires a response 
from an individually addressed MS 



CACH AT bit=busy 



C 

MSB 



iinioioiozoii 



-Response from MS(B) to the BS 



Slot available for random access 

^WW Slot withdrawn, random access not 



Figure 6.5: Withdrawn Slots Example 
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The TSCC transmits PDUs inviting random access: 

a) Aloha PDUs invite random access. Therefore an MS is permitted to transmit a random access PDU. The 
CACH following each of the Aloha PDUs sets the AT bit to O2. Aloha PDUs never withdraw slots but an 

Aloha PDU with Mask=24, MS address=NULL, shall specifically prohibit random access even though the slot 
is not withdrawn; 

b) TSCC transmits a PDU that demands a response followed by the CACH with the AT bit set. The result is that 
the following slot but one at "C" is withdrawn - i.e. not available for random access. The TSCC withdraws that 
slot because the PDU "B" requires response from a specific MS(B); 

c) MS(B) transmits its acknowledgment PDU; 

d) If the slot chosen for the random access attempt is not available because the slot is withdrawn, the MS shall 
choose another slot for a subsequent random access attempt using the random backoff procedures specified in 
clause 6.2.1.1.6. 



6.2.1.1.4 



TSCC responses to Random Access attempts 



After receiving a random access PDU, the TSCC shall send a response. Valid responses are specified in the clauses 
detailing the registration and call procedures. The response may be sent in the TDM A- frame following the random 
access PDU or it may be delayed. The TSCC shall use a NRand_Wait information element in the C_ALOHA PDU to 
specify the delay (in TDMA-frames) a MS shall wait before choosing another slot using a random backoff timer for a 
repeat random access attempt. 



6.2.1.1.5 



Noting the response delay 



An MS shall note the delay parameter NRand_Wait from each C_ALOHA PDU it receives and shall use table 6.2 
below to derive from it the number of TDMA-frames, NWait, by which the TSCCs response to a random access PDU 
may be delayed. (NWait = means that the response is expected by the MS in the TDMA-frame following the random 
access PDU.) At the start of a session, until it receives an Aloha PDU, the unit shall assume a default value of 
NWait = NDefault_NW. 

Table 6.2: System Response delays indicated by the delay parameter NRand_Wait 



NRand Wait 


Nwait(TDMA-frames) 








1 


1 


2 


2 


3 


3 


4 


4 


5 


5 


6 


6 


7 


7 



NRand Wait 


Nwait(TDMA-frames) 


8 


8 


9 


9 


10 


10 


11 


11 


12 


12 


13 


13 


14 


15 


15 


24 



6.2.1.1.6 



Random Backoff 



This clause specifies the method to manage the TSCCs receipt of random access PDUs. A system periodically 
broadcasts a random back-off timer (specified in TDM A frames). 

When a MS initiates a call, the MS may send its first random access PDU in the next slot (subject to Mask, Service 
Function and withdrawn slot specified in clauses 6.2.1.1 a), b) and c)). 

The MS shall invoke the random backoff procedures specified in this clause if: 

a) The MS could not make its random access attempt because access was inhibited by Mask; 

b) The MS could not make its random access attempt because access was inhibited by the Service Function; 

c) The MS could not make its random access attempt because the slot was withdrawn; 

d) The MS did make a random access attempt but that attempt was unsuccessful (the TSCC did not respond 
before the expiry of Nrand_Wait). 
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If the MS makes a random access attempt and is unsuccessful, the MS shall choose a slot for its next random access 
attempt by choosing a random number between the limits of one and the backoff parameter using a statistically uniform 
distribution. 

Figure 6.6 shows a TSCC using parameters NRand_Wait=0. The most recent value of back-off received=4. 

^ Expected TSCC response window for Nrand_Wait=0 



TSCC i 


1 1 


\ 


1 1 


1 1 


1 1 


1 1 


1 1 


1 


1 


1 






\ 

A 


B 


1 


2 


3 


4 








MS 
Inbound 









a) 
b) 



Figure 6.6: Random Backoff Example #1 

At [A] the MS makes a random access attempt. NRand_Wait=0 indicates that the TSCC will respond in the 
next TDMA frame at [B]; 

After TDMA frame [B] a response has not been received, therefore the MS chooses one of the slots 1, 2, 3, 4 
randomly for its next access attempt. 



Figure 6.7 shows a TSCC using parameters NRand_Wait=l. The most recent value of back-off received=4. 

Expected TSCC response window for Nrand_Wait=l 



TSCC 
Outbound 




1 i 


i 


L 


























t 




B 


111 \ z Z ^4 


MS 
Inbound 


i 




1 















a) 
b) 



Figure 6.7: Random backoff Example #2 

The MS makes a random access attempt. NRand_Wait=l indicates that the TSCC will respond in one of the 
next two TDMA frames at [B]; 

After TDMA frame [B] a response has not been received, therefore the MS chooses one of the slots 1, 2, 3, 4 
randomly for its next access attempt. 



A number of outbound channel PDUs including an Aloha PDU contain the backoff information element. 

NOTE: Future releases of the standard may define CACH messages that contain this information element. 

The backoff may be altered by the TSCC and broadcast to MS to respond to varying load conditions presented to the 
system throughout the course of operation. If the system has a light traffic load, the backoff may be small, so decreasing 
random access latency. If the traffic load increases a longer backoff may be warranted to spread competing of random 
access attempts from different MSs by the TSCC transmitting a larger backoff number. This traffic load may be 
estimated from historical usage or may be calculated from the burst traffic being received at that time. 

The backoff parameter may change while the MS is already making random access attempts. When the MS has chosen 
a random slot, that slot shall be preserved for the duration of the current random access attempt. Any new value of 
backoff parameter from the TSCC shall be noted by the MS and shall be employed if the MS needs to choose a new 
random slot for its next random access attempt. 

For PDUs that contain the backoff information element, the number of backoff TDMA-frames is coded, so that more 
backoff TDMA-frames can be realized than a pure binary representation would permit. The explicit numbers of 
TDMA-frames resulting from the back-off number is indicated by table 6.3. 
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Table 6.3: Number of backoff TDMA frames indicated by the Backoff Number 



Backoff Number 


Back-off TDMA Frames 





Reserved 


1 


1 


2 


2 


3 


3 


4 


4 


5 


5 


6 


8 


7 


11 



Backoff Number 


Back-off TDMA Frames 


8 


15 


9 


20 


10 


26 


11 


33 


12 


41 


13 


50 


14 


70 


15 


100 



Note that: 

a) A C_ALOHA PDU with M=24 invites access only for one specific individual MS; 

b) In the example in figure 6.5, if an MS had chosen the slot "C" for a random access attempt, that MS would be 
able to determine that the slot was not available for random access because the slot was withdrawn by 
decoding the AT bit from the CACH and noting that the slot the MS had chosen was withdrawn. The MS 
would abandon that random access attempt, and choose another candidate slot using the random backoff 
parameter; 

c) The MS shall rely on the AT bit to determine if the following random-access slot is withdrawn. If the MS does 
not successfully receive the preceding AT bit, the MS shall assume the slot is withdrawn. 



6.2.1.1.7 



Retry decision and time-outs 



After sending a random access PDU, a MS shall wait to receive a response from the TSCC. Various PDUs shall be 
accepted as a valid response (as specified in the clauses detailing the registration and call procedures). 

The MS shall abandon its access attempt if it has sent the maximum permitted number of random access for the 
particular service requested and received no valid response. This number depends on the service and priority of service 
being requested: 

• For non-emergency random access requests, it is NRand_NR. 

• For emergency random access requests, it is NRand_NE. 

The MS shall also operate a time-out TRand_TC that defines the maximum time it waits trying to achieve random 
access, and abandon the attempt if this time-out expires. 

If the unit's access attempt fails as a result of TRand_TC timeout then: 

a) if the MS has not transmitted a PDU, it shall return to the idle state (and may indicate the failure to the user); 

b) otherwise, (the MS has made at least one random access attempt) if the TRand_TC timer expires while the MS 
is waiting Nwait+1 for the last random access attempt, the MS will complete the Nwait+1 TDMA- frames 
before abandoning its random access. 
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6.2.1 .1 .8 Random Access (non-emergency) SDL for a MS as defined in clause 6.2. 

Figures 6.8 to 6.10 illustrate the non-emergency random access procedures SDL. 



process RandomAccess 



/* MS Random Access procedure fori 
n on -emergency call initiation. */ 



MS has received matching 
n C_ALOHA PDU with random backoff, 
mask, service function, NRand_Wait 



Inflate random access 
servbe request 




set 

(WaitSlot, 

TSelectedSlot) 



WaitRaSlot 



1(3) 



Figure 6.8 (sheet 1 of 3): Random Access Procedure SDL 
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process RandomAccess 



TS_RspP 



m 



WaitRaSlot 




y^^ ^ 'Slot^^ J Either by AT bit in CACH or 

Svithdray^ IVIask=24 and IVIS Addr=NULL 



C_RAND 



N Retry := 
N Retry + 1 



set J Set a timer/counter for the NWait 

(TNWait) time 



RandomBa^kOff | WaitTsRsp 



WaitTsRsp 



reset 
(TNWait) 



Different TSCCPDUs 
may be received as 
appropriate responses 
to the Random Access 
PDU. 



TNWait 



reset 
(TRand_TC) 



ContSetup 



Idle 



^^'"^ ^^ctiv^^ 
^[TRandJGf 



RandomBaJ)kOff 




false 



WaitTsRsp 



TRand TG 




2(3) 



Idle 



false 



WaitTsRsp 



Idle 



Figure 6.9 (sheet 2 of 3): Random Access Procedure SDL 
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process RandomAccess 



Idle 




3(3) 



In case of Emegency call 
limit NRand NE is used. 



Wai 



aitBackOffAloIha 



C ALOHA< 



TRand_TG( 



Update Mask; 
ServiceFunctioi 




NRand_Wait, 
and Backoff 
values' 



Idle 



(RandomBackOff, 
WaitSlot)' 



^ From all states 

(WlaitBackOffAloha) except WaitBackOffAloha 



C ALOHA< 



'Update Mask, 
ServiceFunction, 



NRand_Wait, 
and Backoff 
values' 



Figure 6.10 (sheet 3 of 3): Random Access Procedure SDL 
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6.2.1 .1 .9 Random Access (emergency) SDL for a MS as defined in clause 6.2. 

Figures 6.11 to 6.13 illustrate the emergency random access procedures SDL. 



process EmergencyRandomAccess 



/* MS Random Access procedure for 
emergency service request initiation 



Idle 



MS has received matching 
1 C_ALOHA PDU with random backoff, 
mask, service function, NRand_Wait 



PTT_REQt 



set 
(TRand_TC) 



yes 



NRetry := 




:;Mask = 24^ 



yes 



'$elect RandorcL 
Access Slot 



(WaitSlot 
trSelectedSlotj 



RandomBackoff 



WaitRaSlot 



Emergency Random Access 
service request 



/* No check of service functionK 
needed for emergency service 
request V 



(RandomBackOff, 
WaitSlot)' 



1(3) 



Figure 6.11 (sheet 1 of 3): Emergency Random Access Procedure SDL 
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process EmergencyRandomAccess 



WaitRaSlot 



TSelectedSlot 




Either by AT bit in CACH or 
Mask=24 and MS Addr=NULL 



C_RAND 



N Retry := 
N Retry + 1 



RandomBatkOff 



(TNWait) 



WaitTsRsp 



J Set a timer/counter for the NWait 
time 



WaitTsRsp 



TS_RspP 



d6 



reset 
(TNWait) 



Different TSCCPDUs 
may be received as 
appropriate responses 
to the Random Access 
PDU. 



TNWait 



ir^Band^JCf 



reset 
(TRand_TC) 



ContSetup 



Idle 



2(3) 



TRand TG 




false 



WaitTsRsp 



RandomBadkOff 



Idle 



TRand_Ti 



Active 
(TNWa 



false 



true 



WaitTsRsp 



Idle 



Figure 6.12 (sheet 2 of 3): Emergency Random Access Procedure SDL 
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process EmergencyRandomAccess 



3(3) 



false 



Retry^^ ^ In Emegency call the value 

NRand_NE is used. 




'Select Random^ 
Access Slot 



(RandomBackOff, 
WaitSlot)' 



set 

(WaitSlot, 

rrSelectedSlot) 



Idle 



aitBackOff Aloha 



WaitRaSlot 



aitBackOff Aloha 



^ From all states 

(WaitBackOffAloha) except WaitBackOffAloha 



C_ALOHA< 




TRand_TG 



C_ALOHA< 



NRand_Wait, 
'Update Mask,^ a^^ Backoff 
values' 



Idle 




6.2.1.2 



Figure 6.13 (sheet 3 of 3): Emergency Random Access Procedure SDL 



Action after receiving an acknowledgement 



The MS shall not re-transmit any further random access PDU when an appropriate acknowledgement has been received 
from the TSCC. Various PDUs that are acceptable in addition to specific acknowledgement PDUs are indicated in the 
procedures specified in the present document. An applicable TSCC response to a random access request shall start an 
MS timer. This timer may be restarted by the reception of a further applicable acknowledgement PDU from the TSCC. 
Two values are specified for this timer. One value TP_Timer shall be used if the random access service requires a 
payload channel (for example a speech or packet data service). The second value TNP_Timer shall be used for services 
that only use the TSCC (for example Registration, Short Data service). 
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6.2.1 .3 MS Arriving on a Control Channel 

Channel access regulation for trunked systems is implemented by a TSCC transmitting signalling on the outbound 
channel with periodic PDUs that define regulated channel access. 

When an MS tunes to a new channel where the recent history of channel activity is unknown, the MS shall establish that 
the TSCC is identified as one that the MS is permitted to access. 

a) The MS shall first wait until it receives a colour code information element. If the colour code being transmitted 
by the TSCC is OOOO2 the MS shall skip the colour code check and check the C_SYScode as specified in 
clause 6.2.1.3 b). If the colour code being transmitted by the TSCC is a value other than OOOO2 the MS shall 
check that this particular channel is transmitting a colour code that is expected by the MS. The MS may 
maintain a list of logical channel numbers and their corresponding colour code assignments (see annex C). 

b) The MS shall wait until it explicitly receives the C_SYScode being transmitted on the TSCC. If the MS is 
authorized to access this TSCC, the MS shall wait for an applicable C_ALOHA PDU before it attempts access 
by random access procedures defined in these clauses. 

6.3 Control Channel Acquisition and Retention 

Unless assigned to a payload channel (including immediately after switch-on), the MS shall attempt to find a TSCC 
appropriate to the MSs selected network. The search for a TSCC may be performed by a general hunt through all likely 
channels or by reference to parameters stored within the MS. A framework for MS hunting is described in annex D. 

A MS shall not make any transmissions on a TSCC unless it is active on that channel. It shall not become active until it 
has received a C_SYScode that authorizes the MS to access that TSCC. 

If an MS is hunting over a number of candidate channels, it shall leave the selected channel as soon as it becomes 
evident that the MS shall not be permitted service. 

The discipline for MSs whilst active a TSCC and the circumstances which may result in a search for a new TSCC are 
the subjects of clause 6.3.2 Control Channel Acquisition Procedures. 

In particular: 

• the method by which the MS searches for an appropriate TSCC; 

• the criteria to which a TSCC must be considered appropriate by the MS - authorization; 

• procedures for returning to the TSCC acquisition procedures. 

The methods specified in this clause recognize that designers of networks may choose from a variety of control channel 
strategies, including both Dedicated Control Channels and Non-dedicated Control Channels. 

These methods may result in the MS encountering a variety of control channel situations, including: 

a) receiving a TSCC which suffers short-term interruptions (radio fading and multi-path reception); 

b) suffering long-term interruptions to TSCC reception during which no appropriate TSCC can be received by the 
MS (Non-dedicated Control Channels, or moving out of range of the network); 

c) being in a location where it is possible for more than one TSCC to be received from the selected network, 
involving the unit in a choice; 

d) being instructed to leave a TSCC; 

e) being instructed to leave or being barred from access to, a TSCC as a result of a network load sharing 
arrangement; 

f) being instructed to sample an alternative TSCC on an adjacent radio site (Vote Now). 
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NOTE: It should be noted that a Non-dedicated Control Channel strategy may only be suitable for small single 

site trunked networks using only a few physical channels. If a multi-site trunked network employed a site 
with a non-dedicated TSCC, the network may find it impossible to connect a wide area call or transport 
services that only used the TSCC for delivery. 

Procedures have been specified in the present document to indicate to MS when they may sample an adjacent site for a 
TSCC that may provide an improved grade of service for the MS user. This is achieved on the TSCC transmitting a 
PDU that invites all MS to leave the TSCC momentarily. During this sample time the TSCC can discontinue call 
transactions. Notwithstanding this, manufacturers may devise their own procedures that will allow a MS to leave the 
current TSCC to sample for an alternative TSCC. However it must be noted that if the MS leaves the TSCC on its own 
volition the MS may miss a TSCC transaction. 

6.3.1 MS Parameter Volatility 

In order to satisfy the procedures specified in this clause, the MS shall retain certain parameters for each selected 
network when the MS is switched off. Other parameters shall be discarded when the MS is switched off. Table 6.4 lists 
the behaviour of each applicable parameter. MS parameters that are not listed in table 6.4 shall assume that it must be 
discarded when the MS is switched off. 

Table 6.4: MS Parameter Volatility for Control Channel Acquisition and Retention 



Parameter 


Clause 


Fixed during MS 

Personalization. 

Retained when MS is 

switched off 


Changes during 
operation and 

retained when MS 
is switched off 


Changes during 

operation and 

discarded when MS 

is switched off 


MODEL 


6.3.2.2.1.1 


X 






NET 


6.3.2.2.1.1 


X 






DMRLA 


6.3.2.2.1.1 


X 






MS Category 


6.3.2.2.1.3 


X 






Acquisition Authorization 
Data 


6.3.2.2.2 


X 

See note 






Logical Channel Hunt List 


Also see annex D 


X 






Additions to the hunt list 
from Announcements 
received 


7.2.20.1 




X 




Any parameter not listed 








X 


NOTE: Length of authorization data is dependent on MODEL. Huge - 10 bits, Large - 8 bits, Small - 5 bits. 
Tiny - 3 bits. 



6.3.2 Control Channel Acquisition Procedures 

Control Channel (TSCC) acquisition consists of the steps of checking the C_S YScode (verification) and, if successful 
measuring the signal quality (confirmation) as shown in figure 6.14. 
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I CONTROL CHANNEl\ 

VERIFICATION and 

I CONFIRMATION j 

\ ^ (Clause 6.3.2) ^ 



VERIFICATION 

(Clause 6.3.2.2.2) <& 

(Clause 6.3.2.2.3) 



CONFIRMATION 
(Clause 6.2.2.3) 




VERIFICATION 

and 
CONFIRMATION 



VERIFICATION 

or 
CONFIRMATION 



6.3.2.1 



Figure 6.14: Verification and Confirmation Steps 



Entry into TSCC Acquisition Procedures 



The TSCC acquisition procedures enable a MS that is not assigned to a payload physical channel to attempt to select a 
TSCC. TSCC acquisition is a procedure that consists of hunting for candidate TSCCs and attempting to verify that the 
MS is authorized to become active on that selected TSCC. 

The MS shall enter into the TSCC acquisition procedures under the following circumstances: 

a) immediately after switch-on; 

a user-initiated change of selected network; 

when it has relinquished the current TSCC under the procedures specified in clause 6.3.3; 

when it has received a P_CLEAR PDU on a payload channel; 



b) 
c) 
d) 
e) 



f) 



when it has sent disconnect PDUs P_MAINT(Maint_Kind=DISCON) or timed-out on a payload physical 
channel; 

when it has received a call P_AHOY(Service_Kind=Cancel Call Service) PDU on a payload physical channel 
which requires it to vacate that physical channel. 



At all times during the TSCC acquisition procedures the MS shall mute its received audio and transmission shall be 
inhibited. 

A framework for TSCC control channel hunting is provided in annex D. 



6.3.2.2 



Identifying a Candidate Control Channel 



When an MS is searching for a suitable control channel, the MS shall examine any signal detected for conformity with 
TSCC structure. The MS shall accept as a candidate TSCC any channel on which a TSCC synchronization sequence is 
detected. 

The method by which the MS identifies candidate TSCCs during hunting is not detailed in the present document. In 
particular no maximum time allowance for this procedure is specified, although attention is drawn to the necessity of 
completing tests as quickly as possible, notably on channels which can be easily rejected as TSCC candidates 
(e.g. invalid parameters from the C_S YScode), since the overall speed of the hunt (and thus efficiency of service to the 
user) depends on the rapidity with which these tests can be carried out. 



6.3.2.2.1 



Checking the System Identity Code 



When the MS has identified a candidate TSCC, it shall examine the values of the C_S YScode fields from the TSCC 
PDUs that transmit the C SYScode information element. 
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The time which the MS may continue to search for a value of C_S YScode information element for verification is not 
specified since this depends on the regularity by which the TSCC transmits PDUs that contain the C_SYScode 
information element. However it should be noted that the essential C_SYScode parameters for TSCC searches are also 
transmitted in the CACH. 

When the MS has selected a C_S YScode information element for verification, it shall decide if it is authorized to 
acquire the TSCC (see clause 6.3.2.2.2). If acquisition is permitted then the MS shall become active on that TSCC and 
start the signal quality checking procedures specified in clause 6.3.2.3. 

Whilst active on a TSCC, after verification but prior to confirmation, the MS shall not transmit any random access 
PDUs, but it shall comply with any applicable PDUs received, as required, provided that to do so does not involve 
transmitting on the TSCC. 



6.3.2.2.1.1 



Structure of the System Identity Code (C_SYScode) 



DMR trunked networks may range from tiny systems consisting of a very small number of sites to very large systems 
covering a wide geographic area. To accommodate this wide range of networks, DMR specifies four network models, 
each with characteristics appropriate to each model. 

Table 6.5: Network Model 



Network 
Model 


Model 
Coding 


Number of 
Networks 


Number of Sites 
per Network 


DMRLA 


Tiny 


OO2 


512 


8 


0to3 


Small 


OI2 


128 


32 


0to5 


Large 


IO2 


16 


256 


0to8 


Huge 


II2 


4 


1 024 


OtolO 



In order to identify the network and site to MSs, a TSCC frequently transmits a C_SYScode. MSs shall examine the 
C_S YScode to determine if they are permitted to become or remain active on the TSCC. The C_SYScode information 
elements are structured as follows. 

Table 6.6: Network Model Description 



Parameter 


Descriptor and section 


Description 


MODEL 


Network Model 


Tiny, Small, Large, Huge 


NET 


Network Identity 


Identifies a particular DMR trunked network 


SITE 




The SITE parameter identifies a particular site within a network 


PAR 




for multiple TSCCs within one TS (site) 



A bit specific representation of the Syscode information element is shown in figure 6.15. The MODEL defines the 
length of the NET and SITE information elements. Table 6.5 shows the effect of this partition. It is likely that in a 
particular geographical area a large number of small networks may be employed but only a small number of large 
networks. The MODEL parameter enables a number of differing archetypal networks to be defined. 

NOTE: The DMRLA parameter illustrated in figure 6.15 is used for registration. The registration protocol is 
specified in clause 6.4.4). 
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6.3.2.2.1.2 



DMRLA(n) n=0 to 10 

Figure 6.15: Allocation of NET and SITE information elements in C_SYScode 

Multiple Control Channels 



DMR trunked networks may operate with one or two TSCCs at a single site. The site may sub-divide the MS population 
to allow load sharing between TSCCs. This facility is provided by the PAR sub-field in the C_SYScode and by control 
categorization of MSs. 



6.3.2.2.1.3 



Control Categorization of Radio Units 



At the time of MS network personalization, the MS shall be allocated a control category (ContCAT) stored in the MSs 
fixed non- volatile storage. Two control categories are available, which are designated A and B. 

The control category governs acquisition and retention of a TSCC, since the PAR sub-field in the C_S YScode indicates 
which MS control categories are allowed to become active. 



6.3.2.2.1.4 



The PAR Sub-field 



The PAR information element occupies two bits of the C_S YScode. The meanings assigned to the four possible values 
of PAR shall be: 

OO2 Reserved. 

OI2 Category A MSs only permitted. 

IO2 Category B MSs only permitted. 

1 12 Category A MSs and B MSs permitted. 
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ITraffic : 


1 


Traffic 1 


T5CC PAk=Olz 


TSCC PAR=102 
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i 
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i 



Traffic 



Traffic 



TSCCPAR=ll2 



EXAMPLE: 



6.3.2.2.2 



Figure 6.16: Multiple Control Channels by PAR 

A wide area DMR trunked network has a number of radio sites that employ one TSCC and one site 
that is equipped with two TSCCs. Differing fleets of MS are personalized such that the total MS 
population is evenly distributed between Category A and Category B units. Referring to 
figure 6.16, Site T is configured with two TSCCs and radiates PAR=01 on the first TSCC and 
PAR=10 in the second TSCC. Any MS, whether Category A or B can become active on the TSCC 
from site 2 and site 3. When MS travel to site 1 however they will cluster on their appropriate 
TSCC. 

TSCC Authorization Procedure 



The MS shall read the C_SYScode being transmitted on the TSCC: 

a) Checking the MODEL: 

The MS shall compare the MODEL transmitted in the C_SYScode on the TSCC with the MODEL stored 
in MS fixed non-volatile storage. If there is no match then the MS unit shall assume that it is not 
authorized to acquire the TSCC under test. 

b) Checking the NET: 

If the MS has successfully verified a) above then: 

■ The MS shall compare the NET transmitted in the SYS code on the TSCC with the NET stored in 
MS fixed non- volatile storage. If there is no match then the MS unit shall assume that it is not 
authorized to acquire the TSCC under test. 
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c) Checking the SITE_Acquisition Authorization Data: 

If the MS has successfully verified a) and b) above then: 

■ The MS shall first check if it has stored any SITE acquisition authorization parameters. If no SITE 
acquisition authorization parameters are stored then no checking of SITE acquisition authorization 
shall be performed. However if the MS holds at least one parameter, each value stored shall be 
compared with the SITE parameter transmitted in the C_SYScode on the TSCC. If there are no 
matches then the MS unit shall assume that it is not authorized to acquire the TSCC under test. 

d) Checking the PAR Sub-field: 

If the MS has successfully verified a), b) and c) above then it shall examine the PAR sub-field in the 
light of its control category held in fixed non- volatile storage. If the control category of the MS is not one 
of the categories permitted access by the PAR sub-field value, then the MS shall assume that it is not 
authorized to acquire the TSCC under test. 



MODEL 


NET 




Acquistion Auth' 


Data 


Acquistion Auth' 


Data 


Acquistion Auth' 


Data 


Acquistion Auth' 


Data 


Acquistion Auth' 


Data 


Acquistion Auth' 


Data 


Acquistion Auth' 


Data 


Acquistion Auth' 


Data 




CAT (A,B) 




Figure 6.17: Checking the C_SYScode 

Figure 6.17 illustrates the TSC Authorization procedure specified in clause 6.3.2.2.2 a), b), c) and d). 



6.3.2.2.3 



Checking the SYS_AREA information element 



If the MS has successfully verified the C_SYScode (according to clause 6.3.2.2.2), then it shall examine the 
SYS_AREA information element from the C_SYScode. The SYS_AREA is formed by applying a mask to the Site 
information element of width specified by DMRLA. 
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The S YS_AREA information element is then compared with a Hst in the Hght of denied registrations appHcable to the 
selected network held by the MS. (That list is discarded when the MS is switched off. see clauses 6.3.2.2.2 and 6.4.2). 

If the value of the S YS_AREA information element under examination matches with any of the records of denied 
registrations applicable to the selected network, then the MS unit shall not be authorized to acquire the TSCC under test. 
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Figure 6.18: SYS_AREA information element from the C_SYScode 

EXAMPLE: A large network has MS personalized with DMRLA=6. The MS retrieves the SYS_AREA 

information element from the C_S YScode and compares that result with each entry in the list of 
denied registrations. If there is a match in any one of the entries then the MS shall not be 
authorized to acquire the TSCC under test. 

6.3.2.2.3.1 Lifetime of SYS_AREA entries in the denied registration list 

The entire denied registration list is discarded when the MS is switched off (see clause 6.4.2). 

If the timer T_DENREG is non-zero, individual entries in the denied registration list shall have a limited lifetime. In 
this case the MS maintains a timer for each of the entries. If the timer for a particular SYS_AREA expires, that 
S YS_AREA shall be removed from the list. 

6.3.2.3 Confirmation - Monitoring the TSCC outbound channel signal quality 

While idle on a control channel the MS shall determine the outbound channel signal quality. This may be 
e.g. examination of the error rate, from measurement of the RE signal strength. 

The MS shall hold two thresholds of signal quality: 

a) One threshold shall be used while the MS is hunting for a TSCC prior to confirmation (see clause 6.3.2). 

b) The second threshold shall be used after verification and confirmation and the MS is idle on the TSCC. 
NOTE: When an MS enters a call set-up phase, it suspends signal quality measurement of the TSCC. 
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6.3.3 MS Leaving a Control Channel 

6.3.3.1 Reasons for Leaving a Control Channel when active but idle 

When active, the MS shall monitor the TSCC and return to hunting procedures if any of these conditions are met: 

a) After confirmation, the bit error rate exceeds the minimum prescribed in clause 6.3.2.3. 

b) The value of C_ S YScode received differs from the value verified during acquisition authorization for a 
NSYSerr consecutive occurrences. 

c) No decodable TSCC PDUs are received by the MS for T_Nosig seconds. 

d) The user initiates a change of selected network. 

e) A C_MOVE PDU applicable to the MS is received . In this case the MS shall note the value of the CONT 
information element from the C_MOVE PDU. 

f) The MS receives N_ACK(Reason=Denied) as a result of sending a random access registration PDU. In the 
case of a random access registration request, the MS shall assume the hunt stage that it was last engaged in 
prior to the registration attempt. 

g) After C_S YScode confirmation, the MS receives N_ACK(Reason=failed) as a result of random access 
registration procedures. In this case the MS shall assume the hunt stage that it was last engaged in prior to the 
registration attempt. 

h) After confirmation, the MS has timed out after a random access registration procedure due to NRand_NR 
being reached or Trand_TC being exceeded. In this case the MS shall assume the hunt stage that it was last 
engaged in prior to the registration attempt. 

i) After confirmation, the MS has timed-out after a random access attempt for a service request, except 
registration, due to NRand_NR or Nrand_NE being reached or Nrand_TC being exceeded. 

6.3.3.2 Leaving a Control Channel Whilst Waiting for Signalling 

A MS waiting for signalling shall leave the TSCC on which it is currently active when any of the following events as 
listed in clause 6.3.3.1 occur - b), c), e). In such circumstances the MS shall retain its state of waiting for signalling 
during any hunting procedures and subsequent TSCC confirmation tests. Any timers relevant to the waiting state shall 
be maintained. 

6.4 Registration, Power Save, and Authentication Procedures 

6.4.1 General 
6.4.1.1 Introduction 

Registration is a method of recording the area or group of areas where a MS is likely to be located within a wide area 
network. This information avoids searching for MSs throughout the whole network, consequently reducing call set-up 
time and TSCC loading. 

A secondary feature is that it provides a means of restricting the service to individual MSs to specific TSs by allowing 
the network to deny other registration requests (see clause 6.4.4.1.4). 

The registration strategy describes two types of registration. The first of these is explicit registration, where registration 
is achieved by means of a MS random access procedure. The second is implicit registration, where registration is 
achieved as the result of any PDUs exchanged between a TSCC and a MS. 

Explicit registration also enables MS to request power save. Power save is prescribed in clause 6.4.7. 
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6.4.1.2 



The Principle 



The principle of registration requires that the MS shall only retain a valid registration record where it has received 
confirmation that it is the same record as that currently held within the network. If a MS fails to receive a response to a 
registration request, this could be due to: 

a) the registration request not being received by the network, in which case the network will regard the previous 
successful registration by the unit as the currently- valid registration record; 

b) the registration request being accepted by the network but the service answer response not being received by 
the MS, in which case the network will regard the unsuccessful registration by the unit as the currently- valid 
registration record. 

Accordingly, in such cases the MS is not able to confirm whether the network holds a valid record for the unit and if it 
does, whether it is the previous registration or the present registration. The MS shall therefore only replace its current 
registration record when a successful registration is confirmed by a suitable service answer response to the registration 
service random access request from the TSCC. 

The registration record shall be extracted from the C_SYScode using the following procedure: 

a) The MS extracts the SITE parameter from the C_SYScode. 

b) The MS then extracts the S YS_AREA information from the SITE parameter by masking the most significant 
bits (MSBs) with DMRLA. 
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EXAMPLE: 
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Figure 6.19: Extraction of the registration record from the C_SYScode 

Figure 6.19 shows a Large Network. The SITE parameter for a Large Network has a field length 
of 8 bits. DMRLA in this example=6, therefore the most significant 6 bits become the registration 
record. 



6.4.2 MS Parameter Volatility 

In order to satisfy the procedures specified in this clause and annex D, the MS shall retain certain parameters for each 
selected network when the MS is switched off. Other parameter shall be discarded when the MS is switched off. 
Table 6.7 lists the behaviour of each applicable parameter. 
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Table 6.7: MS Parameter Volatility for Registration 



Parameter 


Clause 


Fixed during MS 
Personalization. Retained 
when MS is switched off 


Changes during 

operation and retained 

when MS is switched off 


Changes during 
operation and discarded 
when MS is switched off 


The Current 
Registration Record 


6.4.4 




X 




List of Denied 
Registrations 


6.3.2.2.3 
(see note 1 ) 






X 


NOTE 1 : At least 8 different values of SYS_AREA information element from the received C_SYScode verified when 

acquiring the TSCC on which a registration attempt by the MS has been denied. These shall be managed as a 
FIFO list: when the MS has a full list of entries, any further addition to the list shall displace the earliest entry. 

NOTE 2: Individual entries in the Denied Registrations list may be deleted by expiry of the denied registrations timer 
T_DENREG (see clause 6.3.2.2.3.1 and 6.4.4.1 .4). 



6.4.3 Action on confirmation of a TSCC 

A MS shall not make any attempt at random access until TSCC confirmation has been achieved. 
When a MS confirms a TSCC it shall either: 

a) if the Reg information element (carried in C_ALOHA PDUs and in the CACH) is zero, the MS shall not seek 
to register by random access nor shall it create or alter any registration record. The MS shall note that 
registration is not required and that it is free to initiate calls; or 

b) if the verified S YS_AREA information element from the C_S YScode matches any entry in the list of denied 
registrations then the MS shall not be authorized to acquire the TSCC under test. The MS shall resume 
hunting; or 

c) if the MS does not hold a successful registration record for the verified S YS_AREA, the MS shall attempt to 
register by random access. 

Once confirmed on a TSCC, the MS shall not transmit any PDU other than: 

a) registration service random access request PDU; or 

b) an acknowledgement to an authentication challenge as specified in clause 6.4.8.3; 

until it holds a successful registration record relating to the verified SYS_AREA unless Reg = 0. 

If the MS holds a successful registration record relating to the verified S YS_AREA code, it is free to transmit any PDU 
conforming to the requirements of the present document. 

6.4.4 Registration Procedures 

The procedures for explicit MS registration are prescribed in clauses 6.4.4.1 to 6.4.4.9. Figures 6.21 to 6.23 illustrate the 
registration process MSCs including the optional authentication step. 



6.4.4.1 



Registration by Random Access 



When a MS determines that it is required to register, it shall attempt to do so by random access using the procedures 
defined in clause 6.2. If the random access timeout C_RandTC expires and the MS has not sent a random access 
registration request, the MS shall enter the TSCC acquisition procedures. 

Immediately upon sending the registration request by random access, the MS shall delete its current SYS_AREA code 
retained from its previous registration. 

Valid TSCC responses to the random access request are C_WACKD(Reason=Wait) more signalling to follow, 
C_ACKD(Reason=Reg_Accepted), C_NACKD(Reason=Reg_Refused), C_NACKD(Reason=Reg_Denied), or 
C_AHOY(Source Address or Gateway=AUTHI) (see clause 6.4.8). 

NOTE: AUTHI is the authentication identifier (see clause A.4). 
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6.4.4.1.1 



Intermediate Acknowledgement 



If the TSCC cannot respond immediately to the random access request, it can send a C_WACKD(Reason=Wait) to the 
MS. This acknowledgement shall start timer TNP_Timer in accordance with clause 6.2.1.2. If further signalling is not 
received after the expiry of the timer, the MS shall comply with the procedures in clause 6.4.4.1.6. 



6.4.4.1.2 



Registration accepted 



The registration attempt shall be considered successful on receipt of ACK(Reason=Reg_Accepted). The MS shall 
record the SYS_AREA information from the TSCC C_S YScode. The MS shall replace any old registration record with 
the new record extracted from the C SYScode. 



6.4.4.1.3 



Registration Refused 



The registration attempt shall be considered to have been unsuccessful if the MS receives 
C_NACKD(Reason=Reg_Failed). 

The MS shall resume hunting, and after confirming a TSCC and receiving a suitable C_ALOHA PDU, shall 
re-commence a random access registration attempt. 

NOTE: Until a successful registration is achieved, the MS shall not attempt to transmit other than random access 
registration service requests. 



6.4.4.1.4 



Registration Denied 



The registration attempt shall be considered denied if the MS receives C_NACKD(Reason=Reg_Denied). The MS shall 
add the SYS_AREA code to the list of denied registration records and enter the TSCC acquisition procedures. 

If T_DENREG is non-zero the MS shall start a timer equal to the value of T_DENREG for that entry in the denied 
registration list 

6.4.4.1 .5 Challenge and Response Authentication 

The TSCC may apply an intermediate step of authenticating the MS during the registration procedure. 
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Figure 6.20: Registration with autlientication check 

Figure 6.20 shows a MS registration procedure with the optional steps "B" and "C": 

a) At "A" the MS makes a random access registration attempt. 

b) The AHOY PDU at "B" is the acknowledgement to the random access and challenges the MS to respond with 
its authentication response. The timer TNP_Timer timer is started. 

c) "C" is the MS response to the TSCC containing the authentication response. 

d) The final C_ACKD or C_NACKD is sent on the TSCC to the MS. 
The specific authentication procedures are prescribed in clause 6.4.8. 



ETSI 



60 ETSI TS 1 02 361 -4 V1 .2.1 (2006-09) 

6.4.4.1 .6 Registration Attempt Times Out 

If the MS times out from waiting for further signalHng for the registration (expiry of timer TNP_Timer), it shall enter 
the TSCC acquisition procedures. 

6.4.4.1.7 Registration Demand Received During Random Access Registration 

The TS shall avoid conflict in the protocol. If, while waiting for a response to a random access registration request 
PDU, the MS receives a C_BCAST(Announcement_type=MassReg) PDU applicable to the MS, the MS shall note the 
information elements from the C_BCAST and initiate the procedure specified in clause 6.4.5.1 then continue with its 
registration request in accordance with the random access procedures. 

6.4.4.1 .8 No answer response Received after the maximum number of random access 
attempts 

If no response is received within WAIT+1 slots after the MS has transmitted NRand_NR random access attempts, the 
MS shall make no consequential changes to its registration record. 

6.4.4.1 .9 Registration Action on Switch-on or equivalent 

If an MS determines that the TSCC requires MS to register, the MS shall register by random access on switch on or 
change of selected network. 
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6.4.4.1 .10 Registration scenario IVISC 

Illustration of the explicit registration procedure as defined in clauses 6.4.4.1 to 6.4.4.' 



MSC MS_Registration 



Successful 
registration 



Failed 
registration 



Denied 
registration 



Failed 
registration 



CCL MS 



DLL 



opt 



alt 
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Figure 6.21 : MS Registration MSC 
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6.4.4.1.11 



Registration with IVIS authentication 



process RegistrationWithAuthentication 



/* Example of MS performing successful registration 
with authentication procedure. V 



WaitRaSlot n 



Registration required has 
^ been identified and the random 
access slot selected. 



TSelectedSlot n 



'MaskCheck' 



C_RAND 
(registration 



N Retry := 
N Retry + 1 



set 
(TNWait) 



WaitTsRsp 



Assumed to occur before 
TRand_TC timeout 



J Assumed to result in 
selected slot available 



J Set a timer/counter for the NWait 
time 



1(2) 



Figure 6.22 (sheet 1 of 2): Registration with Authentication SDL 
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process RegistrationWithAuthentication 



C_ACKU 
(authresp) 



WaitRegAck 



WaitRegAck 



2(2) 



WaitTsRsp 



C_AHOY / J Assumed to occur before 
(challengeK timeout of TNWait and TC_RAND 




(challenge, key, authresp) 



C_ACKD / _ J Assumed to occur before 
(Reg_Acce|3ted) timeout of TNP_Timer 



reset 
(TNP_Timer) 



Active 



Figure 6.23 (sheet 2 of 2): Registration with Authentication SDL 

6.4.5 Mass re-registration 

A wide area network relies on the integrity of the registration records for MS location management. It is possible that 
the records may be suspect for many reasons including loss of connections between the various TS. This clause 
describes a mechanism whereby a TSCC may re-establish those registration records from the MS that are currently 
confirmed on that TSCC. A broadcast PDU is transmitted on the TSCC that causes all applicable MS that are confirmed 
to re-register by random access. If this re-registration procedure is activated it is essential to avoid congestion from the 
increased random access activity that would result. To manage this process therefore, a Reg_Window information 
element is transmitted in the broadcast PDU that permits MS to make their random access registration attempt over an 
extended period of time. 

An MS shall note the delay parameter Reg_Window from the C_BCAST(Announcement_type=MassReg) PDU it 
receives and shall use table 6.8 to derive from it a time window to make a random access registration attempt. 
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The Mass registration may be used to demand a registration from a specific MS by setting the MS address in the Mass 
Registration Broadcast PDU to the individual address of a MS and setting the Mask = 24. 

6.4.5.1 Procedure for MS on receipt of Mass Re-registration Broadcast 

When confirmed on a TSCC a MS shall make use of information C_BCAST(Announcement_type=MassReg). This 
PDU may be transmitted on the TSCC to cause all MS or a subset of the MS population to re-register by random access. 

A MS shall note the population subdivision contained in each C_BCAST(Announcement_type=MassReg) PDU that it 
receives (as prescribed in clause 6.1.3) using the qualifier (Mask) and the address field from the C_BCAST PDU. For 
Mask = to 24, the PDU is appHcable to the MS if the "Mask" least significant bits of the C_BCAST address 
information element match the "Mask" least significant bits of its individual address. 

Table 6.8: Reg_Window lookup for Mass-Registration 



Reg_Window 


Treg_Window 





Cancel Mass Reg 


1 


0,5 


2 


1 


3 


2 


4 


5 


5 


10 


6 


20 


7 


30 



Reg_Window 


Treg_Window 


8 


100 


9 


300 


10 


1 000 


11 


3 000 


12 


10 000 


13 


30 000 


14 


100 000 


15 


200 000 



If the MS determines that the C_BCAST(Announcement_type=MassReg) PDU is appHcable, the MS shall: 

a) examine the Reg_Window information element from the C_BCAST(Announcement_type=MassReg). If the 
Reg_Window information element is non-zero, the MS shall derive the window size TReg_Window (in 
seconds) for a Random Access Registration attempt using table 6.8; 

b) choose a random number (using a statistically uniform distribution) from zero to TReg_Window; 

c) count real time seconds until the random value is reached; 

d) make a random access registration attempt using the procedures prescribed in clause 6.4. If the MS is in power 
save mode, the PowerSave_RQ information element in the Service_Options of the registration service request 
shall be set to maintain the power save mode currently in operation; 

e) also count real time seconds until the TReg_Window slot is reached. If the MS receives other applicable 
C_BCAST(Announcement_type=MassReg) containing a non zero Reg_Window information element before 
Reg_Window is reached the MS shall ignore that C_BCAST PDU; 

f) if Power Save is in operation, the TSCC shall ensure that the Mass-Registration is transmitted in the wake 
period. 

If the MS is confirmed on a TSCC and the MS receives other applicable C_BCAST(Announcement_type=MassReg) 
containing a zero Reg_Window information element the mass re-registration procedure and any pending random access 
attempt shall be cancelled. If such a broadcast is received when the random access procedure is in progress that random 
access procedure shall be completed before the mass re-registration procedure is cancelled. 

If the MS leaves the currently confirmed TSCC, and successfully confirms a different TSCC, any Mass -registration 
procedure shall be cancelled. 

6.4.6 De-registration 

When an MS is switched off, or a user initiated change of system is invoked, the MS may first attempt to de-register 
from the current system. It shall attempt to do so by random access using the procedures defined in clause 6.2. In the 
Service_Options of the registration service request the information elements shall be set to IP_Inform=02, 

Reg_Dereg=02 and PowerSave_RQ=0002 

When an MS switch-off or change of network is performed, the MS shall start a timer T_Dereg. 
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Immediately upon sending the de-registration request by random access, the MS shall discard its current SYS_AREA 
code retained from its previous registration. 

The only valid TSCC response to the de-register random access request shall be C_ACKD(Reason=Reg_Accepted). If 
the acknowledgement is received, the MS shall complete the switch off or change of network. 

If timer T_Dereg expires, the MS shall abandon the de-registration procedure and complete the action of switch-off or 
change of network. 

6.4.7 Power Save 
6.4.7.1 Overview 

Tier III systems may support a synchronized power saving feature. 

An MS can synchronize to the timing parameters that have been exchanged with the TSCC and adopt a periodic sleep 
cycle. Calls to that MS shall be synchronized to the wake-up periods (power save frames) that are agreed between MS 
and the TSCC. 

I POWER SAVE FRAME = 480mS for TDMA channel 2 j 

I ^ POWER SAVE FRAME = 480mS for TDMA channel 1 \ ^ 



TSCC 
Outbound 



UUUU UU =ffl 




PS_Counter=n [OI2] PS_Counter=n [IO2] PS_Counter=n [II2] 



[OO2] 



Figure 6.24: Power Save Frame Structure 

The power save frames are defined by the PS_Counter information element, a sub-set of the Common_Slot _Counter 
broadcast in the CACH. A sleeping MS shall wake for a designated power save frame. If the TSCC has a PDU or 
transaction for the sleeping MS, that PDU shall be queued until a designated power save frame is transmitted on the 
TSCC. MS or other entity that initiates a transaction to a sleeping MS (or group of MSs) shall be queued on the TSCC 
until the designated power save frame has been reached. Figure 6.24 shows a power save frame. For each logical 
channel there are eight slots available to signal MS during a designated power save frame. 

a) The MS and TSCC shall have previously synchronized a particular wake frame. 

b) The TSCC must know when a particular MS has woken and is able to receive signalling addressed to that MS. 
If several MSs are in a fleet and are party to a talkgroup call, all MSs in that particular talkgroup may share the 
same wakeup frame. The way in which the TSCC manages the power save and allocates particular wakeup 
frames is not prescribed in the present document. 

c) Different MSs sharing a common TSCC may have differing power save and the TSCC/MSs must be able to 
deal with this. 

d) The Short LC that carries the Power Save Counter does not have to be continuously transmitted. When MS 
have received a Power Save Short LC they are able to calculate power save frames from that point. MS may 
then refresh by occasional appropriate short LC PDUs. 
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6.4.7.2 



Power Save Procedures 



6.4.7.2.1 



Basic Power Save Procedures 



For a MS to activate power save, it registers with the TSCC. In the registration service request the MS may ask for 
power save it wishes to employ, by sending a non-zero three bit PowerSave_RQ information element with a number 
between 1 and 7. A registration service request with a zero PowerSave_RQ indicates that no power save is required or a 
previous power save is cancelled. The TSCC responds positively if it supports power save for that request, with a 
Powers ave_Off set information element (length 7) in the range to 1, to 3, to 7, to 15, to 31, to 63 or to 127. 

Table 6.9: Power Save information elements during MS registration 



Power Save 


PowerSave RQ 


PowerSave Offset 


OFF 








1:2 


1 


Otol 


1:4 


2 


0to3 


1:8 


3 


0to7 


1:16 


4 


0to15 


1:32 


5 


0to31 


1:64 


6 


0to63 


1:128 


7 


to 127 



A PowerSave_RQ=l indicates the MS shall sleep for one Power Save Frame and awake for the second. A "2" indicate 
1 awake and 3 sleeping. A "3" indicates 1 in 8 awake and so on. In this example the greatest power save would be "7" 
indicating 1 in 128 awake as shown in table 6.9. 

The TSCC responds with an acknowledgement containing a PowerSave_Offset information element (the 
Responsejnfo information element in the acknowledgement PDU) that indicates the power save frame number that the 
TSCC will send signalling to that particular MS. The TSCC may therefore average out signalling across all power save 
frames for differing fleets (or differing talkgroups). The frame number is read by the MS and a mask applied according 
to the power save request. The answer gives the power save frame number for that power save value asked for in the 
registration request. The MS can then calculate when to wake for incoming traffic. 

EXAMPLE: A MS requests a power save of 4 by setting the value of PowerSave_RQ = 2 in the registration 
service request. The TSCC responds with Powersave_Offset = 2. 

The PS_Counter is counting up continuously. Suppose the PS_Counter at this moment = 65 Decimal- 



Table 6.10: Power Save Example - MS state 



PS Counter 


Count 


Mask Counter with PowerSave RQ 








65 


OIOOOOI2 



















1 


66 


010 001 O2 
















1 





67 


01000112 
















1 


1 


68 


01001002 













1 








69 


01001012 













1 





1 


70 


01001102 













1 


1 
























MS state 



Sleep 



Wake 



Sleep 



Sleep 



Sleep 



Wake 



Table 6.10 shows how a TSCC determines when a MS is awake. The TSCC applies a mask of length PowerSave_RQ. 
In this example the mask leaves two bits. When the masked PS_Counter equals the PowerSave_Offset the TSCC may 
signal the MS. 

MS can sample the CACH at any time, read the Common_Slot Counter and determine when the wake frame will be 
transmitted. The MS may then sleep until a point at which its wake frame is scheduled. A PDU addressed to the MS by 
its individual address shall cause the MS to awaken for T_Awake seconds. Each MS individually addressed or 
applicable talkgroup address PDU transmitted on the TSCC or MS shall refresh T_Awake. If no PDUs have been 
transmitted or received by the MS when T_Awake expires the MS shall return to its sleeping state retaining its previous 
power save settings. 
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If an MS awakes and receives an applicable C_AHOY PDU that will result in a payload channel being assigned, the MS 
shall stay awake for a time T_Pending for the Channel Grant PDUs to be transmitted. When that call is completed and 
the MS returns to the TSCC, the MS shall wait for T_Awake seconds and then return to the sleeping state. 

If while awake, the MS receives a C_MOVE PDU, the MS shall retain its T_Awake timer and return to its sleeping 
state after T_Awake expires, unless the move to the replacement TSCC causes the MS to re-register when new power 
save information elements shall be exchanged. 

6.4.8 Authentication Procedures 

Authentication is a procedure to verify that a MS (or TSCC) is genuine. The procedures rely on a key that is shared 
between an individual MS and the TS. When authenticating an MS, a convenient point for applying the authentication 
procedure is during MS registration. When a MS attempts to register by random access, the TSCC sends a random 
number in a C_AHOY PDU (the challenge). The MS calculates the response to the challenge, using a key using a 
standard algorithm (RC4). 
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Figure 6.25: Challenge and Response Authentication 

Figure 6.25 shows the mechanism. The MS calculates the response to the challenge. The TSCC uses the same algorithm 
and the same K,RAND values as the MS. The TSCC then compares the expected response with the actual response. If 
the responses match then the authentication is considered successful. 



6.4.8.1 



Key Management 



A 56 bit authentication key (K) is programmed into each MS. Key generation is specific to each manufacturer and not 
specified in the present document. The (K) of each MS is also programmed into the TS. (K) is intended to be valid for 
the lifetime of the MS, but if (K) is compromised for a particular MS, a manufacturer may choose to re-program the key 
(K) both in the MS and in the network management. 

NOTE: A compromised key only affects one MS and not the entire system. 



6.4.8.2 



Authentication Procedures for the TSCC to authenticate a IVIS 



The TSCC challenges an MS by transmitting a C_AHOY PDU to an individual MS address and information elements 
as shown in table 6.11. If the C_AHOY is transmitted as part of the registration procedure, the Service_Options_Mirror 
is set to the Service_Options from the C_Rand PDU. If the C_AHOY is transmitted as an authentication poll from the 
TSCC (and unconnected with a registration procedure) the Service_options_Mirror shall be set to 000 OOOO2. 

Table 6.11 : C_AHOY information elements for authentication challenge 



Service Options IVIirror 


7 




Service_Kind_Flag 


1 


O2 


Reserved 


2 


OO2 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


IIIO2 


Target address 


24 


Address of Called MS 


Source Address or Gateway 


24 


Authentication challenge value 
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6.4.8.3 



Authentication Procedures for the MS 



If an MS receives an applicable C_AHOY PDU it shall pass the authentication challenge value to the authentication 
algorithm. The result from this algorithm is a 24 bit authentication result. That is transmitted to the TSCC by a 
C_ACKU PDU. 

Table 6.12: Authentication response elements 



Source Type 


1 


^2 - Acknowledgement sourced by MS 


Responsejnfo 


7 


000 OOOO2 


Reason Code 


7 


OIOOIOO2 


Reserved 


1 


O2 


Target address 


24 


authentication challenge response 


Additional Information (Source Address) 


24 


MS individual address that is transmitting the acknowledgement 



6.4.9 MS Stun/Revive 

MS may be denied access to certain tier III services using the stun mechanism. If a MS has been disabled by a stun 
procedure, the MS may not request nor receive any user initiated services on the network that performed the procedure. 
However hunting and registration, authentication, stun / unstun and registration services shall remain active. 

While an MS is stunned, it may also retain the NMEA (lEC 61162-1 [8]) polling service described in clause 6.6.5.1.5. 

In the present document, MS shall only be stunned/revived from a TSCC gateway STUNI as described in 
clause 6.4.9.1.1. 



6.4.9.1 



MS Stun/Revive without authentication 
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Figure 6.26: MS Stun/Revive Procedure 

Figure 6.26 shows the mechanism where the MS does not demand authentication prior to the stun. 

a) The TSCC sends a C_AHO Y at "A" . 

b) MS makes an appropriate acknowledgement at "B". 

6.4.9.1 .1 Stun / Revive procedures for the TSCC 

The TSCC transmits a C_AHOY with the information elements as shown in table 6.13. 

Table 6.13: C AHOY information elements for Stun/Revive 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


02to stun, l2to revive 


Reserved 


2 


OO2 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Supplementary Service - 11 01 2 


Target address 


24 


Individual Address of Called MS 


Source Address or Gateway 


24 


STUNI (see clause A.4) 
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a) If the response is C_ACKU(Reason=Message_Accepted) the TSCC shall interpret the acknowledgement that 
the stun / revive procedure was successful. 

b) If the response is C_NACKU (Reason=MSNot_Supported) the TSCC shall interpret the acknowledgement that 
stun / revive is not supported by the MS. 



6.4.9.1.2 



Stun / Revive procedures for the MS 



If the MS receives an applicable stun/revive C_AHO Y but the MS does not support stun / revive it shall respond with 
C_NACKU(Reason=MSNot_Supported). 

If the MS receives an applicable stun/revive C_AHO Y and the MS supports stun / revive it shall examine the 
Service_Kind_Flag, call the appropriate stun or revive procedure and respond with C_ACKU 
(Reason=Message_Accepted) . 



6.4.9.2 



MS Stun/Revive with authentication 
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Figure 6.27: MS Stun/Revive with Authentication 

Figure 6.27 shows the mechanism where the MS demands authenticates the TSCC prior to the stun: 

a) The TSCC sends a C_AHOY at "A" to stun the MS. 

b) The MS makes its authentication challenge at "B" by transmitting a C_ACVIT PDU. This Ackvitation sent by 
the MS is the acknowledgement to the initial C_AHOY from the TSCC. 

c) At "C" the TSCC sends the challenge response to the MS. The MS authenticates the challenge response. If the 
challenge response is ratified by the MS, the MS stuns/revives and sends 

C_ACKU(Reason=Message_Accepted. If the challenge response fails authentication, the MS shall send 
C_NACKU(Reason=Recipient_Refused) ("D"), and the MS shall not stun. The TSCC may repeat step "C" if a 
response is not successfully received at "D". 

d) The final acknowledgement is sent to the TSCC. 

6.4.9.2.1 Stun / Revive procedures with authentication for the TSCC 

The TSCC transmits a C_AHOY with the information elements as shown in table 6. 13. 

If the MS response is a C_Ackvitation (Target Address=AUTHI, Source Address=challenge value) the TSCC shall 
interpret that PDU as an acknowledgement and that the TSCC is being challenged that the TSCC is authentic. 

The TSCC shall send the response C_ACKD(Reason=Message_Accepted) with the information elements as shown in 
table 6.14. 

Table 6.14: Authentication Response Elements 



Reserved 


1 


O2 


Responsejnfo 


7 


000 OOOO2 


Reason Code 


8 


010000002 


Reserved 


1 


02 


Target address 


24 


authentication challenge response 


Additional Information (Source Address) 


24 


AUTHI (see clause A.4) 
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When the TSCC response to the challenged has been transmitted to the MS, the MS shall send a final 
acknowledgement: 

a) If the final acknowledgement transmitted by the MS is C_ACKU(Message_Accepted) the TSCC shall identify 
that the stun/revive procedure was successful. 

b) If the final acknowledgement transmitted by the MS is C_NACKU(Recipient_Refused) the TSCC shall 
identify that the authentication was unsuccessful. 



6.4.9.2.2 



Stun / Revive procedures with authentication for the IVIS 



If the MS receives an applicable stun/revive C_AHO Y but the MS does not support stun / revive it shall respond with 
C_NACKU(Reason=MSNot_Supported). 

If the MS receives an applicable stun/revive C_AHOY the MS may authenticate the TSCC by transmitting a 
C_Ackvitation with information elements as shown in table 6.15. 

Table 6.15: C_Ackvitation - MS challenges the TSCC 



Service_Options_Mirror 


7 


0000 OOO2 


Service_Kind_Flag 


1 


02to stun, l2to revive 


Reserved 


2 


O2 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Supplementary Service - 1 101 2 


Target address 


24 


AUTHI (see clause A.4) 


Source Address or Gateway 


24 


Authentication Challenge Value 



The MS shall examine the response to the authentication challenge and validate the authentication. The MS shall then 
send a final acknowledgement C_ACKU(Reason=(Message_Accepted) if the authentication was successful or 
C_NACKU(Reason= Recipient_Refused) if the authentication was unsuccessful. 

If the MS supports stun / revive it shall then examine the Service_Kind_Flag, and call the appropriate stun or revive 
procedure. 

Table 6.16: Final Acknowledgement 



Source Type 


1 


I2 - Acknowledgement sourced by MS 


Responsejnfo 


7 


000 OOOO2 


Reason Code 


8 


Message_Accepted - 0100 OIOO2 




Recipient_Refused - 001 1 OOOO2 


Reserved 


1 


O2 


Target address 


24 


AUTHI (see clause A.4) 


Additional Information (Source Address) 


24 


MS Individual Address 



6.4.10 MS Kill 

MS may be completely and permanently disabled using the kill mechanism. If a MS has been killed by a kill procedure, 
the MS shall lose all DMR functionality. An MS may not be revived from the kill state by any AI generated message. 

In the present document, MS shall only be killed from a TSCC gateway KILLI. 
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Figure 6.28: MS Kill (with Authentication) 

Figure 6.28 shows the mechanism for MS kill: 

a) The TSCC sends a C_AHOY at "A" to kill the MS; 

b) The MS makes its authentication challenge at "B" by transmitting a C_ACVIT PDU. This Ackvitation sent by 
the MS is the acknowledgement to the initial C_AHOY from the TSCC; 

c) At "C" the TSCC sends the challenge response to the MS. The MS authenticates the challenge response. If the 
challenge response is ratified by the MS, the MS sends C_ACKU(Reason=Message_Accepted). Following the 
acknowledgement the MS disables all DMR functionality; 

d) If the challenge response fails authentication, the MS shall send C_NACKU(Reason=Recipient_Refused) 
("D"), and the MS shall not kill. The MS may repeat step "B" if the challenge response is not successfully 
received by the TSCC at "C". 

NOTE: A situation may exist where the final acknowledgement C_ACKU was sent by the MS (and the MS 

disabled all functionality) but the acknowledgement was not received by the TSCC. In this case, repeating 
the kill procedure from step "A" would not result in any response from the MS. The TSCC must be able 
to deal with this situation. 

6.4.1 0.1 Kill procedures with authentication for the TSCC 

The TSCC transmits a C_AHOY with the information elements as shown in table 6.17 

Table 6.17: C AHOY information elements for Kill 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


O2 


Reserved 


2 


OO2 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Supplementary Service - 11 01 2 


Target address 


24 


Individual Address of Called MS 


Source Address or 
Gateway 


24 


KILLI (see clause A.4) 



If the MS response is a C_Ackvitation (Target Address=KILLI, Source Address=challenge value) the TSCC shall 
interpret that PDU as an acknowledgement and that the TSCC is being challenged that the TSCC is authentic. 

The TSCC shall send the response C_ACKD(Reason=Message_Accepted) with the information elements as shown in 
table 6.18. 
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Table 6.18: Authentication Response Elements 



Reserved 


1 


O2 


Responsejnfo 


7 


000 OOOO2 


Reason Code 


8 


010000002 


Reserved 


1 


02 


Target address 


24 


authentication challenge response 


Additional Information 
(Source Address) 


24 


KILLI (see clause A.4) 



When the TSCC response to the challenge has been transmitted to the MS, the MS shall send a final acknowledgement. 

a) If the final acknowledgement transmitted by the MS is C_ACKU(Message_Accepted) the TSCC shall identify 
that the kill procedure was successful; 

b) If the final acknowledgement transmitted by the MS is C_NACKU(Recipient_Refused) the TSCC shall 
identify that the kill was unsuccessful. 

6.4.1 0.2 Kill procedures with authentication for the MS 

If the MS receives an applicable kill C_AHO Y but the MS does not support kill it shall respond with C_NACKU 
(Reason=MSNot_Supported) 

If the MS receives an applicable kill C_AHOY the MS shall authenticate the TSCC by transmitting a C_Ackvitation 
with information elements as shown in table 6.19. 

Table 6.19: Authentication Response Elements 



Service_Options_Mirror 


7 


0000 OOO2 


Service_Kind_Flag 


1 


O2 


Reserved 


2 


O2 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Supplementary Service - 1 101 2 


Target address 


24 


KILLI (see clause A.4) 


Source Address or 
Gateway 


24 


Authentication Challenge Value 



The MS shall examine the response to the authentication challenge and validate the authentication. The MS shall then 
send a final acknowledgement C_ACKU(Reason=(Message_Accepted) if the authentication was successful or 
C_NACKU(Reason= Recipient_Refused) if the authentication was unsuccessful (shown in table 6.20). 

Table 6.20: Final Acknowledgement 



Reserved 


1 


O2 


Responsejnfo 


7 


000 OOOO2 


Reason Code 


8 


Message_Accepted - 0100 OIOO2 


Recipient_Refused - 001 1 OOOO2 


Reserved 


1 


O2 


Target address 


24 


KILLI (see clause A.4) 


Additional Information 
(Source Address) 


24 


MS Individual Address 



6.4.1 1 IP Connection Advice 

For a MS to forward an IP connection address to the tier III network, the MS makes use of the registration procedures 
specified in clause 6.4.4 to register (or repeat the registration) with the TSCC (see note). In the registration service 
request the Service Options contain the IP_Inform information element. If the MS registers with the IP_Inform=l2 , the 
TSCC invokes the UDT procedures and sends a AHOY to ask the MS for an IP connection address. 
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a) The MS may repeat this procedure if it has additional IP addresses to send to the system; 

b) The MS may delete an IP connection by sending a registration service deregister with Reg_Dereg=02 and 
IP_Inform=l2 (This combination of information elements does not deregister the MS). 

If the TSCC has the IP addresses for MS registered, the TSCC is able to cross reference the IP address with the MS 
individual address if the MS has activated power save. 

The PDU exchange to add or subtract an IP connection and request power save is shown in Figure 6.xx 

NOTE: The MS may already be registered with the system. Repeating the registration procedure is however a 
convenient mechanism to convey IP connection addresses. 



UDT Uplink 



TSCC 
Outbound 



MS(A) 
Inbound 



Ai\ |ah| |,:^,| |al| |ak| |al 


\ A 1 |b 

{ k \ 


1 1 c 1 1 

j H ) 1 Ad| 


1 1 t> 

1 1 
[ 1 



Figure 6.29: MS IP Connection Advice 

Figure 6.29 shows a MS registration procedure with the optional steps "B" and "C": 

a) At "A" the MS makes a random access registration attempt with IP_Inform=l2; 

b) The AHOY PDU at "B" is the acknowledgement to the random access and asks the MS to respond with the IP 
connection advice. The timer TNP_Timer timer is started; 

c) "C" is the MS response using the UDT IP format; 

d) The final C_ACKD or C_NACKD is sent on the TSCC to the MS. 

6.4.1 1 .1 IP Connection Advice procedures for the MS 

When a MS determines that it wished to advise a change of IP connection (i.e. add or delete an IP address), it shall 
attempt to do so by the registration procedures specified in clause 6.4.4. The indication that a registration request is for 
the purpose of IP connection advice is the information element IP_Inform=l2 in the Service Options. 

Valid TSCC responses to the random access request are defined in clause 6.4.4.1 - C_WACKD(Reason=Wait) more 
signalling to follow, C_ACKD(Reason=Reg_Accepted), C_NACKD(Reason=Reg_Refused), 
C_NACKD(Reason=Reg_Denied), or C_AHOY(Source Address or Gateway=Authentication challenge value) (see 
clause 6.4.8). 



6.4.11.1.1 



Registration Attempt Times Out 



If the MS times out from waiting for further signalling for IP connection request and the MS was not previously 
registered, (expiry of timer TNP_Timer), it shall enter the TSCC acquisition procedures. If the MS was previously 
registered, the MS shall return to the TSCC idle state. 

6.4.1 1 .1 .2 No answer response received after the maximum number of random access 
attempts 

If no response is received within WAIT+1 slots after the MS has transmitted NRand_NR random access attempts, the 
MS shall make no consequential changes to its registration record. 

6.4.1 1 .1 .3 IVIS response to C_AHOY inviting the IVIS to send an IP address 

The MS shall send the IP address using the UDT mechanism. 
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6.4.1 1 .1 .4 Final acknowledgment to IP connection advice received by the calling MS 

The MS may receive C_ACKD(Reason=Reg_Accepted), C_NACKD(Reason=Reg_Refused), 
C_NACKD(Reason=Reg_Denied)(see clause 6.4.4). 

The MS may receive C_ AC KD=Reg_ Accepted. In that case the MS shall assume that the IP connection advice was 
accepted by the TSCC. 

If the TSCC refuses the IP connection advice the MS may receive C_NACKD(Reason=IP_Connection_f ailed). In that 
case the MS shall assume that the IP connection advice has not been accepted by the TSCC. No change in the 
registration record shall be made. 

6.4.1 1 .2 IP Connection Advice procedures for the TSCC 

If the TSCC receives a random access registration request attempt with IP_Inform=l2, it shall transmit a C_AHOY 
inviting the MS to send the IP address using the UDT mechanism. 

The TSCC may transmit any of the acknowledgements specified in clause 6.4.4. 

The TSCC may not be able to accept the IP address. In that case the TSCC shall send 
C_NACKD(Reason=IP_Connection_f ailed). The TSCC shall not change the registration record. 

6.5 Unified Data Transport IVlechanism 

A tier III network supports a wide range of services. To support these services, the transporting of data is a very 
conmion necessity. Although Short Data is a primary data service, there are many instances where data needs to be 
transported to support other services. (For example when a MS dials a PABX or PSTN destination, the dialled digits are 
uploaded to the TSCC.) Whether the data remains within the network or is used to support other services, the 
Supplementary Data Transfer Service may be invoked. To reduce the tier III complexity, all data transport using the 
TSCC share a common method - the Unified Data Transport Mechanism. 

a) Supplementary Data Transfer Service: 

1) Inbound transport of destination addresses that are connected through system gateways. 

2) Inbound transport of PSTN and PABX dialling digits from MS. 

3) Inbound transport of IPV4/IPV6 addresses. 

4) Inbound transport of a MS address in a number of standard and proprietary formats. 

5) Inbound transport of MS NMEA (lEC 61 162-1 [8]) location information. 

6) Outbound channel transport of remote addresses that are connected through system gateways. 

7) Outbound channel transport of CLI information from PABX/PSTN networks. 

8) Outbound channel transport of IPV4/IPV6 address information from IP networks. 

9) Outbound channel transport of a Source Address in a number of standard and proprietary formats. 

10) Outbound channel transport of NMEA (lEC 61 162-1 [8]) MS location. 

b) Short Data Transfer Delivery Service. 

c) Short Data Polling Service. 

d) Inbound transport of digits for the Call Diversion Service. 

The format for the data transfer is the same for transfers using the outbound channel and transfers using the inbound 
channel. The UDT employs the UDT type (UDT) PDU. The first block is the header as shown in figure 6.30. This block 
carries source and destination addresses, the format of the data being carried, and UDT Format that denotes the service 
being supported. Up to four Appended data blocks may follow the header to carry the data. All blocks of the UDT shall 
be transmitted consecutively. 
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UDT HEADER 


7|6 


5 1 4 3 2 1 


Octet 


^ A 


RSVD FORMAT 


Octet 1 


SAP UDT FORMAT 


Octet 2 


TARGET ADDRESS OR 
GATEWAy(24) 


Octet 3 


Octet 4 


Octet 5 


SOURCE ADDRESS OR 
GATEWAy(24) 


Octet 6 


Octet 7 


Octet 8 


PAD NIBBLE | | UAB 


Octet 9 


HgpF 


OPCODE 



Figure 6.30: UDT Header 

The UAB information element indicates the number of UDT blocks that are appended to this header. For a UDT 
addressed to an individual MS, the A information element denotes if a response to this multi-block UDT is expected. 
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Figure 6.31 : A Short Data call using the UDT mechanism 

Figure 6.31 is just one example showing how the Short Data service makes use of the UDT mechanism. The Short Data 
employs a store and forward technique and the procedures are fully described in clause 6.6.4. 

However the UDT segments are highlighted to show the upload and download phases that are described in these 
clauses. In this example the MBC blocks consist of a Header + one appended block. 
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Figure 6.32: MS to PABX/PSTN Call using the UDT Mechanism 
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Figure 6.32 shows a call set-up for a call from an MS to the PABX/PSTN. Calls to these destinations are characterized 
by the necessity of passing the dialled destination to the system. The UDT mechanism provides an unambiguous 
transfer. In this example the UDT consists of a Header + one appended block. In this example the UDT consists of a 
Header + one appended block for up to 20 dialled digits. 
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Figure 6.33: Call from the PSTN/PABX using the UDT Mechanism 

Figure 6.33 shows a further example of a call from the PSTN. The TSCC has elected to download the CLI information 
to the recipient as part of this call set-up. The Service_Kind information element is passed in the header therefore the 
recipient MS knows the call is inbound and the call is from the PSTN. Since the Service_Kind is known to the recipient, 
a secondary feature of the UDT mechanism is that it may serve as a radio check. Only if the MS responds with a 
positive (C_ACKU) acknowledgement does the call mature. 
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Figure 6.34: UDT mechanism carrying supplementary data 

Figure 6.34 shows how supplementary data may be carried as part of a call. MS(A) wishes to send its GPS position as 
part of a voice call set-up. MS therefore elects to indicate that supplementary data is available in the Service_Options 
information element. The TSCC uploads the supplementary data and passes the data to the recipient. The UDT 
download/acknowledgement also serves as the radio check. 

6.5.1 Format of the appended data 

The format of the appended data is specified in annex B. The standard formats are: 

a) Address format - the appended block(s) contain DMR addresses. 

b) Binary Format - the appended block(s) contain binary data. 

c) BCD format - the appended blocks contain digit coded. 

d) 7 bit text coded - the appended data is text coded using ISO 7 bit character set (ISO/IEC 646 [11]). 
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e) 8 bit character coded - the appended data is character coded using ISO 8 bit character set (ISO/IEC 8859 [12]). 

f) NMEA (lEC 61 162-1 [8]) location format - the appended data is coded specifically for NMEA 
(lEC 61162-1 [8]) position data. 

g) 16 bit Unicode format [9]. 

6.5.1.1 UDT Block Structure 

The UDT block structure is described in TS 102 361-1 [5], clause 8.2.2.3. 



6.5.1.2 



UDT Content for Services Carried on the Outbound channel 



The UDT outbound channel mechanism may be invoked as part of a DMR service. The UDT head PDU contains all 
parameters for a MS or talkgroup UDT. The data to be downloaded is held in the TSCC and the information elements 
formed as table 6.21. 

Table 6.21 : UDT Outbound channel information elements 



UDT Outbound channel Mechanism 






UDT Outbound channel PDUs 




Service 


Operation 


Service 
Kind 


Supple 

mentary 

Flag 


UDT- 
Format 


UDT_ 
Response 


Target 

address or 

gateway 


Source or 
gateway 
Address 


MS Response 
to Head+Data 


Voice Call 
from PSTN 
to 

Individual 
MS 


Send CLI 
information 
from PSTN 


Individual 

Voice Call 

Service 

(0001 2) 


I2 


BCD 
(001 O2) 


O2 option 


Destination 
MS Address 


PSTNI 


No 


1 2 option 


ACK, NACK 


Voice Call 
from PABX 
to 

Individual 
MS 


Send CLI 
information 
from PABX 


Individual 

Voice Call 

Service 

(0001 2) 


I2 


BCD 
(001 O2) 


O2 option 


Destination 
MS Address 


PABXI 


No 


1 2 option 


ACK, NACK 


Voice Call 
from PSTN 
to 
Talkgroup 


Send CLI 
information 
from PSTN 


Talkgroup 

Voice Call 

Service 

(001 O2) 


I2 


BCD 
(001 O2) 


02 


Destination 
Talkgroup 


PSTNI 


No 


Voice Call 
from PABX 
to 
Talkgroup 


Send CLI 
information 
from PABX 


Talkgroup 

Voice Call 

Service 

(001 O2) 


I2 


BCD 
(001 O2) 


02 


Destination 
Talkgroup 


PABXI 


No 


Voice Call 
from MS to 
Individual 
MS 


Send NMEA 
information 
from Source 
MS 


Individual 

Voice Call 

Service 

(0001 2) 


I2 


NMEA 
formatte 

d 
(01 01 2) 


O2 option 


Destination 
MS Address 


Source 
MS 


No 


1 2 option 


ACK, NACK 


Voice Call 
from MS to 
Individual 
MS 


Send 

supplementar 
y text PDU as 
part of call 
setup 


Individual 

Voice Call 

Service 

(0001 2) 


I2 


7 bit txt 
(0011 2) 


O2 option 


Destination 
MS Address 


Source 
MS 


No 


1 2 option 


ACK, NACK 


Short Data 
call from 
MS to MS 


Short Data 

Outbound 

Phase 


Indiv" Short 

Data 

(OIOO2) 


O2 


UDT_Fo 
rmat 


I2 


Destination 
MS Address 


Source 
MS 


ACK, NACK 


Short Data 
call from 
Dispatcher 
to MS 


Short Data 

Outbound 

Phase 


Indiv" Short 

Data 

(OIOO2) 


O2 


UDT_Fo 
rmat 


I2 


Destination 
MS Address 


DISPATI 


ACK, NACK 


Send 
Diverted 
address to 
caller 


See clause 6.6.7 
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The information elements of the PDUs in the UDT Header information elements are summarized: 



UDT Format 



Appended_Blocks 
Supplementary_Flag 



UDT_Response 



Service_Kind 

Target _address or Gateway 

Source_address or gateway 



specifies the format of the data transported in the appended data blocks of the 

multi-block UDT 

if the UDT outbound is the second phase preceded by a UDT Inbound, the 

UDT_Format shall be copied from the UDTJnbound Header 

specifies the number of appended data blocks concatenated to the header 

specifies if: 

- this UDT Header is carrying the data for a user initiated service (e.g. Short 
Data Delivery); or 

- this UDT Header is carrying supplementary data, supporting another service 
specifies if the TSCC is expecting a response from this UDT download: 

- if the UDT download is addressing an individual MS then: 

* if the UDT download is supporting an Supplementary _Data transfer then 
this information element may be set or clear 

* for the Short Data Service then this information element shall be set to ^2 

- response expected 

- if the UDT download is addressing a talkgroup then: 

* the UDT information element shall be set to O2 - response not expected 
specifies the service being supported by the UDT mechanism 

individual MS address or Talkgroup or AII_Unit 
source MS address for a service originating from an MS 
PABXI for a service originating from a PABX extension 
PSTN! for a service originating from the PSTN 
IPI for a service originating from an IP network 



6.5.1.3 



UDT Mechanism for the Inbound channel 



The UDT inbound channel mechanism is invoked as part of a DMR service. The UDT head PDU contains all 
parameters for the UDT. The data to be uploaded is set as table 6.22. This table is not exhaustive and many other 
arrangements are possible to support tier III services. 
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Table 6.22: UDT Inbound channel information elements 



UDT Inbound channel Mechanism 








UDT Inbound channel information elements 


Service 


Operation 


Service_Kind 


Supple 
mentary 

Flag 


Format 


UDT 
Response 


Target 

address or 

gateway 


Source 

Address or 

gateway 


Voice Call 
from 

Individual 
MS to PSTN 


Send PSTN 
dialling 
information 
from MS 


Individual 

Voice Call 

Service 

(0001 2) 


I2 


BCD) 
(0001 2) 


O2 (N/A) 


PSTNI 


MS Address 


Voice Call 
from 

Individual 
MS to PABX 


Send PABX 
dialling 
information 
from MS 


Individual 

Voice Call 

Service 

(0001 2) 


I2 


BCD 
(0001 2) 


O2 (N/A) 


PABXI 


MS Address 


Voice Call 
from MS to 
Individual 
MS 


Inbound NMEA 
information 
from Source 
MS 


Individual 

Voice Call 

Service 

(0001 2) 


I2 


NMEA 
(01 01 2) 


O2 (N/A) 


Destination 
MS 


MS Address 


Short Data 
call from MS 
to MS 


Short Data 
Inbound Phase 


Indiv" Short Data 
(OIOO2) 


O2 


UDT_For 
mat 


O2 (N/A) 


Destination 
MS 


Source MS 


NMEA 
polling from 
a gateway 


Short Data 
Inbound Phase 


Short data 

polling serv" 

(01 11 2) 


O2 


NMEA 
(01 01 2) 


O2 (N/A) 


Destination 
MS 


ATSCC 
Gateway 


Call 

Diversion 

Service 


Diversion 
Inbound phase 


Call Diversion 

serv" 

(OIIO2) 


O2 


value 


O2 (N/A) 


DIVERTI 


MS 


Authenticatio 
n 


Inbound MS 
Authentication 


Authentication 
serv" 


O2 


AUTH 
(01 11 2) 


O2 (N/A) 


AUTHI 


MS 


IP Address 
registration 


Inbound IP 
address 


Registration 
Service 


I2 


IP 

(OIIO2) 


O2 (N/A) 


TSI 


MS 



The Key protocol aspects of the information element settings in the UDT Header feature elements are: 
UDT Format 



Appended_Blocks 
Supplementary_Flag 



UDT_Response 

Service_Kind 

Target _address or Gateway 



Source_address or gateway 



specifies the format of the data transported in the appended data blocks of the 
multi-block UDT 

specifies the number of appended data blocks concatenated to the header 
specifies if: 

- this UDT Header is carrying the data for a user initiated service (Short Data, 
Data Polling); or 

- this UDT Header is carrying supplementary data, supporting another service 
N/A 

specifies the service being supported by the UDT mechanism 

target MS address 

PABXI for a service to a PABX extension 

PSTNI for a service to the PSTN 

I PI for a service to an IP network 

Source MS address or gateway 



6.6 Call procedures 



Access to Tier III Services from MS shall be by random access using the random access protocol described in 

clause 6.2. The C_RAND CSBK random access PDU contains all parameters necessary to signify the particular tier III 

service requested. 

a) Individual Voice Call Service. 

b) Talkgroup Voice Call Service. 

c) Individual Packet Data Call Service. 
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d) Packet Data Call Service for a talkgroup. 

e) Individual Short Data Delivery Service. 

f) Talkgroup Short Data Delivery Service. 

g) Call Diversion Service. 

h) Short Data Polling (from an MS) Service. 

i) Include Individual Call Service (Payload Channel only). 

j) Include Talkgroup Call Service (Payload Channel only). 

k) Registration Service (see clause 6.4). 

1) Cancel Call Service. 

To support these services the tier III protocol implements a supplementary data transport mechanism whereby data may 
be carried between entities to support or enhance other services. 

For MS call to an MS, talkgroup or All-MS, the full source and destination address is provided in the C_RAND PDU so 
a single-part call set-up procedure shall be invoked. For MS calls to destinations connected through a gateway (such as 
PSTN), a multi-part call procedure sets an appropriate gateway address as the destination in the C_RAND PDU. The 
TSCC then demands the extended addressing information from the calling MS using the Unified Data Transport Service 
(see clause 6.5). 
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Figure 6.35: Example of Multi-part call procedure 

Figure 6.35 shows an example of a call to a PABX extension: 

a) "A" is the random access C_RAND PDU. The destination address is set to PABXI indicating a multi-part call 
setup for a call service to the PABX. 

b) "B" is a C_AHOY PDU to ask the calHng MS for the PABX extension digits. 

c) The UDT inbound channel "C" contains a multi-block UDT consisting of a header and an appended data block 
containing the PABX extension digits. 

d) The TSCC sends the Channel Grant PDUs to the MS at "D". 

The procedures for Voice and packet data are specified in clauses 6.6.2 and 6.6.3 respectively. The procedures include: 

e) Call Setup: 

1) Random Access Call Request; 

2) Possible AHOY/UDT procedure to provide extended addressing for calls through gateways; 

3) Availability check to called party; 

4) Channel Grant. 

f) Call Management on the payload channel: 

1) Call maintenance; 

2) Call clear-down. 
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6.6.1 Procedures common to Voice calls and Packet Data Calls 

6.6.1 .1 Availability of requesting MS 

A MS requests a call service by transmitting a random access service request. While the call set-up is in progress, the 
TSCC may check that the requesting MS is still in radio contact at any time by sending a C_AHOY PDU addressed to 
it. The C_AHOY PDU demands a response from the calling MS. 

6.6.1.2 Call Cancellation 

If a Voice call service request has been passed to the MS CC layer, and the call is cancelled before the Random Access 
PDU has been transmitted to the TSCC, the MS shall return to the idle state. 

If a MS has initiated a voice call service and the call has not matured (by the transmission of Channel Grant PDUs) the 
call may be cancelled by the calling party initiating a Call Cancel Service request. This is a random access service 
request (Service_Kind=Cancel Call Request). The TSCC response to a call cancel request shall be C_ACKD 
(Reason=Message accepted). 

6.6.1 .3 Acknowledgements sent to calling MS 

From the point at which a MS has requested a particular service, the TSCC may send acknowledgement PDUs to 
indicate to the calling MS the progress of the service request. 

a) The TSCC may send PDUs that complete or terminate the call service request as follows: 

1) The TSCC may send C_NACKD to indicate to the calling MS that the call has failed. The C_NACKD 
PDU contains a Reason code to indicate to the caller why the service request failed. 

2) The TSCC may send a UDT header + appended UDT block to indicate that the call is diverted. From the 
TSCC perspective the service transaction is completed. The MS may choose to indicate the diverted 
address to the caller and return to the idle state, or automatically make a new service request with the 
diverted address as the destination. 

3) The TSCC may send C_ACKD(Reason=Callback) to inform the calling MS that the caller has indicated 
they will call back. 

b) The TSCC may send progress PDUs to the calling MS as a valid response to the random access request as 
follows: 

1) C_WACKD - An intermediate acknowledgement, more signalling to follow. 

2) C_QACKD - The TSCC has queued the call because the resource requested or called party is busy, more 
signalling to follow. 

3) C_AHOY - The TSCC has sent a C_AHOY PDU with the calling MS address in either the Source or 
Target address information element. 

6.6.1 .4 Maintenance of call progress waiting timers 
6.6.1 .4.1 Gall waiting timer for the calling MS 

From the point at which a MS has requested a particular service, the TSCC may send acknowledgement PDUs to 
indicate to the calling MS the progress of the service request. If the calling MS receives an acknowledgement to its 
random access request, it shall start one of two timers. The timer TP_Timer shall be started for any random access 
service request that requires the allocation of a payload channel. The timer TNP_Timer shall be started for a call that 
only uses the TSCC for the call. If, while the timer is running the MS receives another acknowledgement PDU, the 
timer shall be refreshed. If the timer expires, the MS may assume that the TSCC has abandoned the call and the MS 
shall return to the idle state. 
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The TSCC shall maintain an identical timer. If the TSCC receives a random access request for a call that requires the 
allocation of a payload channel, it will start timer TP_Timer. A call that only requires the TSCC shall start timer 
TNP_Timer. The TSCC may send a further acknowledgement to the calling MS and refresh its timer. If the timer 
expires, the TSCC shall abandon that call service. 

6.6.1 .4.2 Call waiting timer for the called MS 

If a MS receives an individually addressed C_AHOY PDU (Service_Kind=00002) or C_AHOY PDU 
(Service_Kind=00102) indicating an availability check for a payload channel, the MS shall start timer T_Pending. 

While T_Pending is running, if the MS receives a Talkgroup voice channel grant or Packet Data Talkgroup Channel 
Grant PDU, the PDU shall be discarded. If the timer T_Pending expires and the MS has not been directed to a payload 
channel, the MS may assume that the TSCC has abandoned the call that was indicated in the C_AHOY PDU. 

If while T_Pending is running, the TSCC transmits another individually addressed C_AHOY PDU 
(Service_Kind=00002) or C_AHOY PDU (Service_Kind=00102), the MS shall refresh timer T_Pending. 

If while T_Pending is running, the TSCC transmits an individually addressed C_AHOY call cancellation PDU 
C_AHOY (Service_Kind=llll2), the T_Pending timer shall be suspended. 

The TSCC shall maintain the same timer T_Pending. If the TSCC transmits a C_AHOY PDU (Service_Kind=00002) or 
C_AHOY PDU (Service_Kind=00102) indicating an availability check for a payload channel, T_Pending is started. If 
the TSCC has not transmitted the Channel Grant PDU(s) for this call before T_Pending expires, the TSCC shall 
abandon the call. 

6.6.1 .5 Payload Channel Assignnnent 

The TSCC shall assign a payload channel for the call by transmitting applicable Channel Grant PDUs for the service 
supported (individual MS or talkgroup). 

The Channel Grant PDUs may be single block CSBK format if the logical channel to absolute Tx / Rx frequency 
relationship is known, or the MBC Channel Grant PDUs may have an appended MBC block that contains the absolute 
Tx /Rx frequencies. 

For individual voice and packet data services to and from certain gateways, the payload channel may select offset 
timing to provide a full duplex service to MS. The TSCC provides a differing gateway identifier to distinguish between 
the aligned and offset mode of payload assignment: 

a) for ahgned timing PSTNI, PABXI, LINEI, IPI, (see clause A.4); 

b) for offset timing PSTNDI, PABXDI, LINEDI, IPDI, (see clause A.4); 

Channel Grant PDUs may be transmitted by the TS on a payload channel to swap the call to a replacement channel. 

If a particular talkgroup call is active on a payload channel, the TSCC may continue to transmit appropriately addressed 
Channel Grant PDUs at regular intervals to permit late joining MSs (MSs who may have just arrived on the control 
channel) to join that talkgroup call. 

6.6.2 Voice Call Procedures 

Voice calls require a payload channel over which the call is conducted. Calls may be transacted between the entities in 
table 6.23. 
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Table 6.23: Voice Call Services 



Mode 


Originator 




Recipient 


Voice 


MS 


- 


MS or Talkgroup 


MS 


- 


All MS (Broadcast) 


MS 




Line Connected destination through a Gateway: 
PABX Extension 
PSTN destination 
Other gateway equipped for voice 


Line Connected source via a Gateway: 
PABX Extension 
PSTN destination 
Other gateways equipped for voice 




MS or Talkgroup or All MS 



The Individual/Talkgroup PDU in the Random Access Service Request shall determine if the caller has selected a tier 
III service to an individual MS or a talkgroup. 

The Service_Options PDU in the Random Access Service Request shall activate options for the Voice Call Service 
Request: 

• Emergency service: 

Emergency calls shall take precedence over all other calls. Emergency call may be pre-emptive causing 
another call to be cleared down if the resource requested for the emergency call is not available. 

• Supplementary Data Transfer Service requested for this call: 

Information may be sent to the called party as part of and to support another call service. For instance the 
PSTN Call Line Identity may be passed to the called party as part of a voice call setup. 

• Broadcast service: 

The Broadcast Call Voice service provides a one-way voice call from any user to a predetermined 
talkgroup. 

• OVCM call: 

The Open Voice Channel Mode service allows users to monitor and participate to the voice channel 
activity. From the voice activity originator's point of view the OVCM gives the opportunity to place 
group and individual calls that may be listened from third party users that are not the targeted users of the 
call. In addition these third party users are part of the conversation in progress and they can also talk. 

Third party users are those that have radios configured to take part to calls set as OVCM and not 
addressed explicitly to them. 

• Priority: 



6.6.2.1 



The priority option permits the originator to select one of four levels of priority. The TSCC may manage 
and manipulate a call queue to cause calls with a higher priority to mature faster. The procedures the 
TSCC may employ are not prescribed in the present document. 

Voice Call Procedures for the TSCC 



A MS requests a tier III voice service by generating a random access request PDU with the Target Address set to one of 
the following: 

a) An individual MS address (single-part call set-up). 

b) A talkgroup MS address (single-part call set-up). 

c) A gateway address that indicates a multi-part call set-up. 

When the TSCC responds to the random access request, it shall start a timer (TP_Timer). This timer shall be refreshed 
if the TSCC sends further call related PDUs C_WACKD, C_QACKD or C_AHOY, to the calling party. 
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6.6.2.1 .1 TSCC Response to single-part voice call set-up 

When a random access voice service PDU is received on the TSCC, the TSCC shall send a response in accordance with 
the random access procedures prescribed in clause 6.2. 

The PDUs that represent a valid response to the voice call single-part service random access request are: 

a) An acknowledgement PDU C_NACKD, C_QACKD, C_WACKD, C_ACKD(reason=callback). 

b) A UDT Head + appended block(s) (voice call is diverted) UDT Header PDUs Source_Address=DIVERTI 
(conveying a diverted address) Supplementary Flag = I2 and UDT_Response = O2. 

c) A C_AHOY PDU (called party radio check) if the call is to an individual MS address. 

d) A Channel Grant PDU(s) for this call. 

6.6.2.1 .2 TSCC Response to multi-part voice call set-up 

For calls to extended addresses, the MS requests multi-part addressing by generating a voice call random access request 
with the Destination Address information element set to a gateway address (PABXI, PSTNI, etc) and the Proxy Flag 
information element to indicate if one or two appended UDT blocks are required to transport the extended address from 
the MS. For calls to the PABX/PSTN one appended UDT can carry up to 20 dialled digits, and in that case the Proxy 
Flag information element shall be set to O2, and for the number of dialled digits = 21 to 44 the Proxy Flag information 
element shall be set to I2. 

The PDUs that shall represent a valid response to the voice call multi-part part voice service random access request are: 

a) An acknowledgement PDU C_NACKD, C_WACKD(reason=Wait), C_QACKD. 

b) A C_AHOY PDU for the calling MS to send the extended address information. 

c) A C_AHOY PDU for the calling MS to send supplementary data (see clause 6.5). 

For b) The TSCC shall then invoke the UDT procedure by sending a C_AHOY to the calling MS to send the extended 
address information. For a call to the PABX or PSTN the extended address information shall be BCD digits. The Proxy 
Flag information element in the C-AHOY PDU shall be copied from the Proxy Flag information element received from 
the MS C_RAND PDU. If the TSCC does not successfully receive the UDT from the MS, the TSCC may repeat the 
C_AHOY, or transmit a C_NACKD to indicate failure of the call. 

For c) The TSCC shall then invoke the UDT procedure by sending a C_AHOY to the calling MS to send the 
supplementary data. The format of the supplementary data is specified in the UDT. If the TSCC does not successfully 
receive the UDT from the MS, the TSCC may repeat the C_AHOY, or transmit a C_NACKD to indicate failure of the 
call, or continue with the call setup and abandon the supplementary data. 

6.6.2.1 .3 Acknowledgements sent on the TSCC to the calling MS (voice) 

The TSCC may send acknowledgement PDUs following the random access voice service request to indicate the 
progress of the call, to terminate the call or indicate call-back. If the TSCC sends a PDU to indicate the progress of a 
call it shall start a waiting timer TP_Timer. (The calling party MS maintains a similar timer): 

a) Progress PDUs are: 

1) C_WACKD: Intermediate acknowledgement. More PDUs to follow; 

2) C_QACKD: Called MS engaged in another call; 

3) C_QACKD: Call is queued because the resource is in use at the moment. 

b) Termination PDUs are selected from an appropriate Reason information element in a C_NACKD PDU (see 
clause 7.2.8): 

1) C_NACKD. 
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c) Call-Back PDUs indicate to the calling MS that the voice call service has been accepted by the called party for 
call back: 

1) C_ACKD(reason=CallBack). 

d) If the TS has previously accepted a call diversion indicating that this type of service request should be directed 
to another called party, the TSCC shall invoke the UDT and send a UDT Head + Appended data to the calling 
party. UDT Header PDUs Source Address=DIVERTI (conveying a diverted address) Supplementary Flag = I2 
and UDT_Response = O2. 

6.6.2.1 .4 Voice Radio Check 

For calls to individual MS, the TSCC shall check that the called party is in radio contact and will accept the call before 
a payload channel is allocated. 

The TSCC may check availability of the called party by: 

a) Sending a C_AHOY PDU to that called party. 

b) Sending a Multi-block UDT with supplementary data (if the supplementary data service is active for this call). 
If a response is not received from the called party the TSCC may repeat the C_AHOY. 

The availability check demands a response from the called party: 

• If the response is C_NACKU, the TSCC shall send an appropriate call failed response to the calling MS and 
echo the Reason in the C_NACKU PDU. 

• If the response is C_ACKU(Reason=CallBack), the TSCC shall send an appropriate CallBack response to the 
calling MS. 

• If the response is C_ACKU(Reason=Message_ Accepted), the TSCC shall progress the service request and 
allocate a payload channel by transmitting appropriate Channel Grant PDUs. 

6.6.2.1 .5 Availability Check for Voice Calls connected through Gateways 

For calls connected through gateways the TS equipment may wait until the destination is ready before allocating the 
payload channel. For example a TS may wait until the PSTN handset has been answered before sending Channel Grant 
PDUs. 

6.6.2.2 Voice Gall Procedures for MS 

A MS is able to request a voice call service to another individual MS or a talkgroup using a single-part service request. 
For a voice service requested to extended addresses through a gateway the MS requests a multi-part service request. For 
multi-part service requests the MS sets the gateway address as the called party. The full destination address is then 
uploaded from the MS to the TSCC by the UDT procedure. 

A MS requests a voice service by sending a C_RAND random access request complying with the random access 
procedures in clause 6.2. The information elements in the random access request are passed to the CC layer - set 
appropriately as prescribed in table 6.24. 
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Table 6.24: C RAND information elements for a Voice Call Service 



Information 
Element (I.E) 


I.E 
Length 


length 


Alias 


Value 


Remark 


Service_Options 


7 




EMERG 


O2 


Non-emergency service 


I2 


Emergency service 






O2 


Privacy (see note 1 ) 




SUPED_SV 


O2 


No Supplementary Data Transfer Service 
required for this call 


I2 


Supplementary Data Transfer Service 
requested for this call 




BCAST_SV 


O2 


Non-broadcast service 


I2 


Broadcast service (see note 2) 




OVCM_SV 


O2 


Non-OVCM call 


I2 


OVCM call 


2 


PRIORTY_SV 
(see note 3) 


OO2 


Normal (low) priority 


OI2 


Medium Priority 


IO2 


High Priority 


II2 


Highest Priority 


Proxy Flag 


1 




PROXY 


O2 


Number of Extended BCD digits for 
addressing through a gateway = 1 to 20 


I2 


Number of Extended BCD digits for 
addressing through a gateway = 21 to 44 


Appended_Supplem 
entary Data 


2 




SUPED_VAL 


Value 


Number of appended UDTs required to 
transport supplementary data 


Appended_Short 
Data 


2 




SDATA_VAL 


OO2 


Not Defined for a Voice Service 


Service_Kind 


4 




IND_V_SRV 


OOOO2 


Individual Voice Call Service 


GRP_V_SRV 


0001 2 


Talkgroup Voice Call Service 


Target_address or 
Gateway 


24 






Value 


Target Address (see note 4) 


Source address 


24 






Value 


Individual Address of the requesting MS 


NOTE 1 : Privacy is not defined in the present document. 

NOTE 2: The broadcast option is only applicable to the talkgoup call service. 

NOTE 3: If EMERG = 1 2 then PRIORTY_SV is set to OO2. 

NOTE 4: If Service_Kind = IND_V_SRV then Target_Address represents an Individual address. 

If Service_Kind = GRP_V_SRV then Target_Address represents a Talkgroup. 
NOTE 5: OVCM calls apply to MS destinations only. 



6.6.2.2.1 



Initiating a single-part voice call service 



For a voice service request to an individual MS or talkgroup, the destination address is completely expressed by the 
Target Address information element in the random access PDU. The Service_Kind specifies if the voice call service is 
addressed to an individual address or a talkgroup. 

6.6.2.2.2 Response to the single-part voice service request 

MS shall accept the following PDUs as valid response to the single-part voice service request. 

a) an acknowledgement C_WACKD, C_QACKD, C_NACKD, C_ACKD(reason=callback); 

b) for an individual call service request, a C_AHOY called party radio check; 

c) a UDT header + appended UDT block. UDT Header Source_Address=DIVERTI (conveying a diverted 
address) Supplementary Flag = I2 and UDT_Response = O2; 

d) a Channel Grant PDU; 

e) if the Service_Options SUPED_SV = I2 a C_AHOY to upload the supplementary data from the calling MS. 
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6.6.2.2.3 Response to the multi-part voice service request 

MS shall accept the following PDUs as valid response to the multi-part voice service request. 

a) an acknowledgement C_WACKD, C_QACKD, C_NACKD; 

b) a C_AHOY PDU to upload the extended address: 

1) for a call to the PABX/PSTN a C_AHOY to upload the dialled digits; 

2) if the Service_Options SUPED_SV = I2 a C_AHOY to upload the supplementary data from the calling 

MS. 

For b), if the Voice Call Service Request requires extended address information and the calling MS has selected the 
Supplementary Data in the Service_Options, the TSCC uploads the information in two steps. The order in which the 
information is uploaded is not prescribed because the C_AHOY specifically indicates which UDT inbound procedure 
has been invoked by setting appropriate unambiguous Gateway information elements in the C_AHOY PDU. The 
gateway information elements for C_AHOY PDUs to support voice services are prescribed in table 6.25. 

Table 6.25: C_AHOY information elements for multi-part voice call setup 



Action 


Gateway 
address 


Remark 


MS send PSTN digits 


PSTNI 


The calling party shall send BCD dialled digits 


MS sends PABX digits 


PABXI 


The calling party shall send BCD dialled digits 


MS sends supplementary data 


SUPLI 


The format of the data shall be determined by the calling party 



6.6.2.2.4 Acknowledgements received by the calling MS (voice) 

At some time after sending the voice service request random access PDU the calling MS may receive an 
acknowledgement. On receiving the acknowledgement, the MS shall start or restart a waiting timer, TP_Timer. (The 
TSCC maintains a similar timer). 

The MS shall take the actions prescribed: 

a) Progress PDUs for a single-part voice call Service Request are: 

1) C_WACKD: Intermediate acknowledgement. More PDUs to follow. The MS shall wait TP_Timer for 
further signalling and may indicate a possible delay to the calling MS; 

2) C_QACKD: Called MS engaged in another call. The MS shall wait TP_Timer for further signalling; 

3) C_QACKD: Call is queued because the resource is in use at the moment. The MS shall wait TP_Timer 
for further signalling and may indicate a possible delay to the calling MS. 

(The MS may choose to differentiate between 1), 2) and 3) by providing the calling MS with a visual or 
audible indication for each of the conditions). 

b) Termination PDUs are selected from an appropriate Reason information element in a C_NACKD PDU (see 
clause 7.2.8): 

1) C_NACKD: Call refused and terminated. The C_NACKD PDU provides a versatile range of Reason 
codes to indicate to the calling party why the Service request was terminated. The calling party shall 
return to the idle state. 

c) Call-Back PDU to indicate to the calling MS that the voice call service has been accepted by the called party 
for call back. Service concluded. The calling party shall return to the idle state: 

1) C_ACKD(reason=CallBack). 



d) If the TS has previously accepted a call diversion indicating that this type of service request be directed to 
another called party, a UDT Head + Appended data indicating the diverted address. 
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6.6.2.2.5 Availability Check to the called MS (voice) 

For an individual MS address call set-up, the called MS shall receive a radio check to which it will respond with an 
appropriate acknowledgement: 

• The called party shall respond C_NACKU, if it cannot accept the call (the TSCC shall send an appropriate call 
failed response to the calling MS). 

• The called party shall respond C_ACKU(Reason=CallBack), if the called MS wishes to return the call at some 
future time (the TSCC shall send an appropriate CallBack response to the calling MS). 

• The calling party shall respond C_ACKU(Reason=Message_Accepted), if the call is accepted (the TSCC shall 
progress the service request and allocate a payload channel by transmitting appropriate Channel Grant PDUs). 

6.6.2.2.6 Payload Channel Allocation 

MS shall check the address information elements received in Voice Channel Grant PDUs. If it is determined that the 
Channel Grant PDU is applicable then it shall retune to the indicated physical/logical payload channel to commence the 
Voice Service. 

a) For Private Voice Channel Grant CSBK PDU: 

1) If an MS receives a Private Channel Grant PDU where either the Source Address or the Target Address 
information element matches its individual address then that PDU is applicable. 

b) Talkgroup Voice Channel Grant CSBK PDU (OVCM information element = O2): 

1) If an MS receives a Talkgroup Channel Grant PDU with the Target Address information element 
matching one of its talkgroup addresses then that PDU is applicable. 

2) If an MS receives a Talkgroup Channel Grant PDU with the Source Address matching its individual 
address then that PDU is applicable. 

3) If an MS receives a Broadcast Talkgroup Channel Grant PDU with the Target Address matching one of 
its talkgroup addresses then that PDU is applicable. 

4) If an MS receives a Broadcast Talkgroup Channel Grant PDU with the Source Address matching its 
individual address then that PDU is applicable. 

c) Talkgroup Voice Channel Grant CSBK PDU (OVCM information element = I2): 

1) If an MS receives a Talkgroup Channel Grant PDU with the Target Address information element 
matching one of its talkgroup addresses or one of its OVCM addresses then that PDU is applicable. 



2) If an MS receives a Talkgroup Channel Grant PDU with the Source Address matching its individual 
address then that PDU is applicable. 

3) If an MS receives a Broadcast Talkgroup Channel Grant PDU with the Target Address matching one of 
its talkgroup addresses or one of its OVCM addresses then that PDU is applicable. 

4) If an MS receives a Broadcast Talkgroup Channel Grant PDU with the Source Address matching its 
individual address then that PDU is applicable. 

6.6.2.2.7 Calling MS in single part voice call setup SDL 

Figures 6.36 and 6.37 SDL is defined from the behaviour description in clause 6.6.2.2. 

NOTE: The state names are not related to state names in TS 102 361-1 and TS 102 361-2. 
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Figure 6.36 (sheet 1 of 2): Single part voice call setup SDL 
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Figure 6.37 (sheet 2 of 2): Single part voice call setup SDL 
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6.6.2.2.8 Call set-up MSC that also transfers supplementary data. 

Figure 6.38 illustrates a call set-up from an MSC where supplementary data is transferred as part of the call set-up. 
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6.6.2.3 



Figure 6.38: MS Call set-up with Supplementary data 



Procedures for the Voice Payload Channel 



MSs are directed to a voice payload physical/logical channel on the TSCC. When the voice call is terminated, MS 
returns to the TSCC and the payload channel is reassigned to another call. 

A voice call may extend over several MS PTT items for the duration of the call (unless the call is terminated 
prematurely by the expiry of the voice payload timer) if the system has assigned the call as "message trunking". If the 
system has assigned the call as pure "transmission trunking" the call shall be terminated after the end of each PTT item. 
A third possibility is that the call has been assigned as "quasi-transmission trunking". In this case a short interval timer 
(TV_Hangtime) between PTT items holds the payload channel. If this short interval timer expires, the call is terminated 
and the next PTT item sets up a new call. 
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The voice payload channel may be assigned to one of two basic timing models. The particular timing model is specified 
on the TSCC and signalled to MS by the Channel Grant PDUs (see TS 102 361-1 [5]): 

a) Aligned timing supports Reverse Channel (RC) signalling by providing the receiving MS with a Reverse 
Channel transmit opportunity on the inbound channel without missing any of its outbound traffic. Aligned 
timing also supports "MS to MS" duplex traffic by allowing a MS to transmit in one timeslot and receive the 
repeated transmission of the other MS on the alternative timeslot: 

1) l:l-mode. 1 traffic channel mode: l:l-mode supports one "MS to fixed end" duplex call or one simplex 
call with an optional inbound Reverse Channel using a two frequency BS. 

2) 2:1 -mode. 2 traffic channel mode: 2:1 -mode supports two independent calls which may be either "MS to 
fixed end" duplex calls or simplex calls using a two frequency BS. 

b) Offset timing supports "MS to fixed end" duplex traffic by allowing a MS to transmit in one time slot and 
receive the fixed end transmission on the alternate time slot. 

The procedures for TS/MS behaviour on the voice payload channel are described in TS 102 361-2 [6]. In the trunked 
environment however, call maintenance PDUs are exchanged between MS and TS in addition to the PDUs described in 
TS 102 361-2 [6]. 

When active, a payload channel shall transmit the CACH in the same form as described in TS 102 361-2 [6], 
clause 7.1.3.2). 

The beginning of a call shall use PATCS method (see TS 102 361-2 [6], clause 5.2.2.1). For an individual MS call 
service, the called party will already have had a radio check as part of the call set-up procedure. 



6.6.2.3.1 



TS Procedures for the Voice Payload Channel 



A physical payload channel may carry one or two independent voice calls. If a new physical channel is allocated on the 
TSCC, the CCL_BS shall start both the CCL_1 and CCL_2 processes as described in TS 102 361-2 [6], 
clause 5.1.1.1.3). and start the voice channel payload timer as follows: 

a) For an individual MS/MS or MS/Talkgroup normal or high priority call T_MS-MS_TIMER. 

b) For a gateway individual MS or Talkgroup normal or high priority call T_MS-Line_TIMER. 

c) For an emergency call T_EMERG_TIMER. 



6.6.2.3.1.1 



MS radio check 



The TS may poll an individual MS to check if the MS is active on the payload channel by transmitting a P_AHOY PDU 
with the information elements set as follows. 

The TSCC transmits a P_AHOY with the information elements as shown in table 6.26. 

Table 6.26: P AHOY information elements for voice service individual radio check 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


O2 


Reserved 


2 


OO2 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Individual Call Service - OOOO2 


Target address 


24 


Individual Address of Called MS 


Source Address or Gateway 


24 


TSI 



The response is P_ACKU(Reason=Message_ Accepted). 

The TS may also poll a talkgroup to check if at least one member of the talkgroup is active on the payload channel by 
transmitting a P_AHOY PDU with the information elements as shown in table 6.27. 
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Table 6.27: P_AHOY information elements for voice service talkgroup radio check 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


O2 


Reserved 


2 


OO2 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Talkgroup Call Service - 0001 2 


Target address 


24 


Address of the talkgroup 


Source Address or Gateway 


24 


TSI 



The response is P_ACKU (Reason=Message_ Accepted). If more than one MS makes a response to this PDU, it is Hkely 
that the TS will be unable to decode it because of collisions. The purpose of this procedure is to determine if any 
talkgroups are active, therefore the TS may use the presence of the burst for the result of the talkgroup radio check. 



6.6.2.3.1.2 



Authentication Check 



The authentication procedures are identical to the authentication procedures described in clause 6.4.8.2 but with the 
C_AHOY PDU replaced by a P_AHOY PDU. 



6.6.2.3.1.3 



Disabling/enabling a users PTT 



The TS may at any time send a P_PROTECT (Protect_Kind=DIS_PTT) addressed to an individual MS, talkgroup, or 
All Unit ID to disable the PTT. Since the P_PROTECT PDU is unacknowledged the PDU may be repeated at layer 2. 

The TS may also at any time send a P_PROTECT (Protect_Kind=EN_PTT) addressed to an individual MS, talkgroup, 
or All Unit ID to enable the PTT. Since the P_PROTECT PDU is unacknowledged the PDU may be repeated at layer 2. 



6.6.2.3.1.4 



Swapping the call to a replacement voice payload channel 



The TS may send Channel Grant PDUs on the payload channel to move MS already active to an alternative voice 
payload channel. If MS had previously received a P_PROTECT to disable their PTT, the PTT shall be re-enabled on the 
replacement voice payload channel unless the call service was a broadcast when called party(s) shall retain their PTT 
status (enable/disable) from the original call. 



6.6.2.3.1.5 



Removing MS from the payload channel that are not legitimate parties 



The TS may transmit P_PROTECT(ILLEGALLY_PARKED) PDUs at any time. A MS whose address does not match 
either of the address information elements in the P_PROTECT PDU shall leave the payload channel without making 
any further transmissions. 

6.6.2.3.1 .6 Clearing down the voice call 

The TS shall clear the parties involved in the payload voice call if: 

a) The relevant overall payload call timer T_MS-MS_TIMER, T_MS-Line_TIMER or T_EMERG_TIMER 
expires. 

b) The TS receives a P_MAINT (Maint_Kind = DISCON) PDU. 

c) The TS detects by any other means that the call has ended (e.g. PSTN destination on hook). 

d) The TV_Hangtime interval timer expires. 

The TS shall clear down the call by transmitting P_CLEAR PDU(s). Since this PDU is not acknowledged it may be 
repeated at layer 2. 
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6.6.2.3.1.7 



TS single part voice call termination MSC 



Figure 6.39 illustrates the MSC showing the TS voice call termination procedure for MS-MS or MS-Talkgroup call on 
payload channel as described in clause 6.6.2.3.1.6. 

NOTE: The option TS detects by other means that the call has ended' is not illustrated in this MSC. 



MSC TS MsMsVoiceCallClearDown 



/* TS voice call clear down of a MS to MS or 
MS to Talkgroup call on payload channel. 7 



TS CCL 



TS DLL 



TS PL 



InCall 



alt 



opt 



T MsMs Timer 

^ E 



TV_Hangtime 



Rx P MAINT 



(Maint_Kind=DISCON) 



Tx_P_CLEAR 



(Cancel Call Service) 



Rx P ACK 



( Message_Accepted) 



Rx CSBK 



(P_MAINT) 



Tx_CSBK 



(P_CLEAR) 



Rx CSBK 



(P_ACK) 



Figure 6.39: Voice Call Termination MSC 
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6.6.2.3.1 .8 Clearing down a particular MS or talkgroup 

The TS may selectively clear an individual MS by transmitting a P_AHOY with information elements set as table 6.28. 

Table 6.28: P_AHOY information elements to clear an individual MS from a voice payload channel 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


O2 Indicates that the target is an Individual Address 


Reserved 


2 


OO2 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Cancel Call Service - 1 1 1 12 


Target address 


24 


Individual Address of MS 


Source Address or Gateway 


24 


TSI (see clause A.4) 



The permitted response is P_ACKU(Message_Accepted). 

The TS may clear a talkgroup by transmitting a P_AHOY with information elements set as table 6.29. 

Table 6.29: P_AHOY information elements to clear a talkgroup from a voice payload channel 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


I2 Indicates that the target is a talkgroup 


Reserved 


2 


OO2 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Cancel Call Service - 1 1 1 12 


Target address 


24 


Talkgroup 


Source Address or Gateway 


24 


TSI 



The permitted response is P_ACKU(Message_Accepted). 



6.6.2.3.2 



6.6.2.3.2.1 



MS Procedures for the Voice Payload Channel 



MS receives an MS radio check 



If an MS receives a P_AHOY to its individual address with information elements set as table 6.26, then it shall respond 
with a P_ACKU (Reason=message_accepted). 

If an MS receives a P_AHOY to the talkgroup address previously transmitted in the Channel Grant PDU that directed 
this MS to the payload channel (PDUs set as table 6.27), then it shall respond with a P_ACKU 
(Reason=message_accepted). 



6.6.2.3.2.2 



MS receives an Authentication Check Challenge 



The authentication procedures are identical to the authentication procedures described in clause 6.4.8.2 but with the 
authentication response C_ACKU PDU replaced by a P_ACKU PDU. 



6.6.2.3.2.3 



Disabling/enabling a users PTT 



If the MS receives a P_PROTECT (Protect_Kind=DIS_PTT) addressed to its individual address, to it is talkgroup 
address previously transmitted in the Channel Grant PDU directed it to the payload channel, or All Unit ID, the MS 
shall disable it is PTT. 

If the MS receives a P_PROTECT (Protect_Kind=EN_PTT) addressed to its individual address, to it is talkgroup 
address previously transmitted in the Channel Grant PDU, or All Unit ID, the MS shall re-enable it is PTT unless this 
MS was the recipient of a broadcast call. 
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6.6.2.3.2.4 MS receives a Channel Grant PDU(s) 

If a MS receives an applicable Channel Grant addressed to its individual address or to it is talkgroup address previously 
transmitted in the Channel Grant PDU directed it to the payload channel, then it shall retune to the designated 
physical/logical channel. If the PTT was disabled prior to receiving the Channel Grant, the PTT shall be re-enabled 
unless this MS was the recipient of a broadcast call set-up or a call to All-Unit ID. 

6.6.2.3.2.5 End of call 

The MS shall signify the end off the call by transmitting a number of P_MAINT (Maint_Kind=DISCON). The MS shall 
send the P_MAINT PDUs consecutively then return to the control channel acquisition procedures (it is suggested that 
the TSCC sampled is the TSCC that transferred the call to the payload channel). 

6.6.2.3.2.6 MS receives P_CLEAR 

If a MS receives a P_CLEAR PDU then it shall move to the TSCC indicated by the Logical Physical Channel Number 
PDU. 

6.6.2.3.2.7 MS receives a selective clear P_AHOY 

If a MS receives an individually addressed P_AHOY, Service_Kind=llll2, Service_Kind_Flag=02 information 
element then it shall send a P_ACKU (Reason=Message_Accepted), abandon the payload channel and return to the 
control channel acquisition procedures (it is suggested that the TSCC initially sampled is the TSCC that transferred the 
call to the payload channel). 

If a MS receives a P_AHOY, Service_Kind=l 1 1 12, Service_Kind_Flag=l2 information element addressed to it is 
talkgroup address previously transmitted in the Channel Grant PDU the talkgroup then it shall send a PACK 
(Reason=Message_Accepted) abandon the payload channel and return to the control channel acquisition procedures (it 
is suggested that the TSCC initially sampled is the TSCC that transferred the call to the payload channel). 

6.6.2.3.2.8 MS receives a P_PROTECT PDU(s) 

If a MS receives a P_PROTECT(ILLEGALLY_PARKED) PDU, and the source or target address in the P_PROTECT 
PDU does not match the source or target address from the Channel Grant PDU that directed the MS to the payload 
channel, the MS shall leave the payload channel without making any further transmissions. 

6.6.2.3.2.9 Time out on the Payload Channel 

A MS shall maintain a number of timers while active on a voice payload channel. 

a) Inactivity timer: 

A MS shall measure the length of time the MS is unable to detect adequate signal quality. If the MS fails 
to detect adequate signal quality for a continuous time TVJnactive, the MS shall assume that the call has 
ended and return to the control channel acquisition procedures without sending any call termination 
signalling (it is suggested that the TSCC sampled is the TSCC that transferred the call to the payload 
channel). 

b) Item Duration timer: 

A MS shall maintain a maximum item duration timer. If the MS reaches the maximum item duration 
TV_Item, the MS shall transmit a Terminator with LC, disable the PTT and wait until the user releases 
the PTT before re-enabling the PTT. 

c) An overall payload call timer: 

If the overall voice payload call timer T_MS-MS_TIMER, T_MS-Line_TIMER or T_EMERG_TIMER 
expires, the MS shall transmit a number (N_Maint) of P_MAINT PDUs consecutively then return to the 
control channel acquisition procedures (it is suggested that the TSCC sampled is the TSCC that 
transferred the call to the payload channel) If the MS was sending speech frames when the overall voice 
payload call timer expires, the MS shall transmit a Terminator with LC prior to transmitting the 
P MAINTPDUs. 



ETSI 



97 



ETSI TS 102 361-4 V1.2.1 (2006-09) 



6.6.3 Packet Data Call Procedures 

Packet data calls require a payload channel over which the call is conducted. Calls may be transacted between the 
entities in table 6.30. 

Table 6.30: Packet Data Call Services 



Mode 


Originator 




Recipient 


Packet Data 


MS 


- 


MS or Talkgroup 


MS 


- 


All MS (Broadcast) 


MS 




Line Connected destination through a Gateway: 
IP Gateway 
Data Gateway 
Other gateway equipped for data 


Line Connected source via a Gateway: 
IP Gateway 
Data Gateway 
Other gateway equipped for data 




MS or Talkgroup or All MS 



A packet data payload channel may support multiple simultaneous calls. 

6.6.3.1 Packet Data Call Procedures for the TSCC 

A MS requests a tier III service by generating a random access request PDU with the Target Address set to: 

a) An individual MS address (single-part call setup). 

b) A talkgroup MS address (single-part call setup). 

c) A gateway address that indicates a multi-part call setup. 

When the TSCC responds to the random access request, it shall start a timer (TP_Timer). This timer shall be refreshed 
if the TSCC sends further call progress PDUs to the calling party. 



6.6.3.1.1 



TSCC Response to single-part packet call set-up 



When a random access packet data PDU is received on the TSCC, the TSCC shall send a response in accordance with 
the random access procedures prescribed in clause 6.2. 

The PDUs that represent a valid response to the packet call single-part service random access request are: 

a) An acknowledgement PDU C_NACKD, C_QACKD, C_WACKD. 

b) A UDT Head + appended block(s) (packet data call is diverted) UDT Header PDUs 
Source_Address=DIVERTI (conveying a diverted address) Supplementary Flag = I2 and 
UDT_Response = O2. 

c) A C_AHOY PDU (called party radio check). 

d) A C_AHOY PDU to upload supplementary data from calling MS. 

e) A Channel Grant PDU(s) for this call. 



6.6.3.1.2 



TSCC Response to multi-part packet call setup 



For calls to extended addresses, the MS requests multi-part addressing by generating a packet data call random access 
request with the Destination Address information element set to a gateway address (PABXI, PSTNI, IPI etc) and the 
Proxy Flag information element to indicate the number of digits for the extended address. For the number of dialled 
digits = 1 to 20 the Proxy Flag information element shall be set to O2. For the number of dialled digits = 21 to 44 the 
Proxy Flag information element shall be set to I2. The PDUs that shall represent a valid response to the voice call multi- 
part part voice service random access request are: 

a) An acknowledgement PDU C_NACKD, C_WACKD(reason=Wait). 
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b) A C_AHOY PDU for the calling MS to send the extended address information. 

c) A C_AHOY PDU for the calling MS to send supplementary data (see clause 6.5). 

For b) The TSCC shall then invoke the UDT procedure by sending a C_AHOY to the calling MS to send the extended 
address information. For a call to the PABX or PSTN the extended address information shall be BCD digits. The Proxy 
Flag information element in the C-AHOY PDU shall be copied from the Proxy Flag information element received from 
the MS C_RAND PDU. 

For c) The TSCC shall then invoke the UDT procedure by sending a C_AHOY to the calling MS to send the 
supplementary data. The format of the supplementary data is specified in the UDT. 

If the TSCC does not successfully receive the UDT from the MS, the TSCC may repeat the C_AHOY or transmit a 
C_NACKD to indicate failure of the call. 

6.6.3.1 .3 Acknowledgements sent on the TSCC to the calling MS (packet) 

The TSCC may send acknowledgement PDUs following the random access data packet service request to indicate the 
progress of the call, to terminate the call. If the TSCC sends a PDU to indicate the progress of a call it shall start a 
waiting timer TP_Timer. (The calling party MS maintains a similar timer). 

a) Progress PDUs are: 

1) C_WACKD: Intermediate acknowledgement. More PDUs to follow. 

2) C_QACKD: Called MS engaged in another call. 

3) C_QACKD: Call is queued because the resource is in use at the moment. 

b) Termination PDUs are selected from an appropriate Reason information element in a C_NACKD PDU (see 
clause 7.2.8): 

1) C_NACKD. 

c) If the TS has previously accepted a call diversion indicating that this type of service request be directed to 
another called party, the TSCC shall invoke the UDT and send a UDT Head + Appended data to the calling 
party. 

6.6.3.1 .4 Radio Check for packet 

For calls to individual MS, the TSCC shall check that the called party is in radio contact and will accept the call before 
a payload channel is allocated. The radio check may also indicate that the called party data terminal equipment is ready. 

The TSCC may check availability of the called party by: 

a) Sending a C_AHOY PDU to that called party. 

b) Sending a Multi-block UDT with supplementary data (if the supplementary data service is active for this call). 
If a response is not received from the calling party the TSCC may repeat the C_AHOY. 

The availability check demands a response from the called party: 

• If the response is C_NACKU, the TSCC shall send an appropriate call failed response to the calling MS and 
echo the Reason in the C_NACKD PDU. 

• If the response is C_ACKU(Reason=Message_ Accepted), the TSCC shall progress the service request and 
allocate a payload channel by transmitting appropriate Channel Grant PDUs. 

6.6.3.1 .5 Availability Check for Packet Calls connected through Gateways 

For calls connected through gateways the TS equipment may wait until the destination is ready before allocating the 
payload channel. For example a TS waits until PSTN equipment has linked the data terminal before sending Channel 
Grant PDUs. 
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6.6.3.2 



Packet Data Call Procedures for MS 



A MS is able to request a packet data call service to another individual MS or a talkgroup using a single-part service 
request. For a packet data service requested to extended addresses through a gateway the MS requests a multi-part 
service request. For multi-part service requests the MS sets the gateway address as the called party. The full destination 
address is then provided by the MS to the TSCC by the UDT procedure. 

A MS requests a packet data service by sending a C_RAND random access request complying with the random access 
procedures in clause 6.2. The information elements in the random access request are passed to the CC layer - set 
appropriately as prescribed in table 6.31. 

Table 6.31 : C RAND information elements for a Packet Data Call Service 



Information 
Element (I.E) 


I.E 
Length 


length 


Alias 


Value 


Remark 


Service_Options 


7 


1 


EMERG 


O2 


Non-emergency service 


I2 


Emergency service 


1 




O2 


Privacy (see note 1 ) 


1 


SUPED_SV 


O2 


No Supplementary Data Transfer Service 
required for this call 


I2 


Supplementary Data Transfer Service 
requested for this call 


1 


HI_RATE 


O2 


Payload channel expects single slot data 
timing 


I2 


Payload channel expects dual slot data 
timing 


1 


OVCM_SV 


O2 


Non-OVCM call 


I2 


OVCM call 


2 


PRIORTY_SV 
(see note 3) 


OO2 


Normal (low) priority 


OI2 


Medium Priority 


IO2 


High Priority 


II2 


Highest Priority 


Proxy Flag 


1 




PROXY 


O2 


Number of Extended BCD digits for 
addressing through a PSTN/PABX gateway 
= 1 to 20. For IP gateway extended address 
is IPV4 


I2 


Number of Extended BCD digits for 
addressing through a PSTN/PABX gateway 
= 21 to 44. For IP gateway extended 
address is IPV6 


Appended_Supplem 
entary Data 


2 




SUPED_VAL 


Value 


Number of appended UDTs required to 
transport supplementary data 


Appended_Short 
Data 


2 




SDATA_VAL 


OO2 


Not Applicable for Packet Data 


Service_Kind 


4 




IND_D_SRV 


001 O2 


Individual packet data Call Service 


GRP_D_SRV 


OOII2 


Talkgroup packet data Call Service 


Target_address or 
Gateway 


24 






Value 


Target Address (see note 4) 


Source address 


24 






Value 


Individual Address of the requesting MS 


NOTE 1 : Privacy is not defined in the present document. 

NOTE 2: The broadcast option is only applicable to the talkgoup call service. 

NOTE 3: If EMERG = 1 ^ then PRIORTY_SV is set to OO2. 

NOTE 4: If Service_Kind = IND_D_SRV then Target_Address represents an Individual address. 
If Service Kind = GRP D SRV then Target Address represents a Talkgroup. 



6.6.3.2.1 



Initiating a single-part packet data call service 



For a packet data service request to an individual MS or talkgroup, the destination address is completely expressed by 
the Target Address information element in the random access PDU. The Service_Kind specifies if the data packet call 
service is addressed to an individual address or a talkgroup. 
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6.6.3.2.2 Response to the single-part packet service request 

MS shall accept the following PDUs as valid response to the single-part data packet service request: 

a) an acknowledgement C_WACKD, C_QACKD, C_NACKD; 

b) for an individual call service request, a C_AHOY called party radio check; 

c) a Channel Grant PDU; 

d) if the Service_Options SUPED_SV = I2 a C_AHOY to upload the supplementary data from the calling MS; 

e) a UDT Head + appended blocks UDT Header PDUs Source_Address=DIVERTI, Embedded_Flag = 1. 

6.6.3.2.3 Response to the multi-part packet data service request 

MS shall accept the following PDUs as valid response to the multi-part data packet service request: 

a) an acknowledgement C_WACKD, C_QACKD, C_NACKD; 

b) a C_AHOY PDU to upload the extended address: 

1) for a call to the PABX/PSTN a C_AHOY to upload the dialled digits; 

2) if the Service_Options SUPED_SV = I2 a C_AHOY to upload the supplementary data from the calling 

MS. 

NOTE: For b), if the Data packet Call Service Request requires extended address information and the calling MS 
has selected the Supplementary Data in the Service option, the TSCC uploads the information in two 
steps. The order in which the information is uploaded is not prescribed because the C_AHOY specifically 
indicates which UDT inbound procedure has been invoked by setting appropriate unambiguous 
information elements in the C_AHOY PDU. 

6.6.3.2.4 Acknowledgements received by the calling MS (packet data) 

At some time after sending the packet data service request random access PDU the calling MS may receive an 
acknowledgement. On receiving the acknowledgement, the MS shall start or restart a waiting timer, TP_Timer. (The 
TSCC maintains a similar timer). 

The MS shall take the actions prescribed: 

a) Progress PDUs for a single-part data packet call Service Request are: 

1) C_WACKD: Intermediate acknowledgement. More PDUs to follow. The MS shall wait TP_Timer for 
further signalling and may indicate a possible delay to the calling MS; 

2) C_QACKD (Reason=1000 0001 2): Called MS engaged in another call. The MS shall wait TP_Timer for 
further signalling and may indicate a possible delay to the calling MS; 

3) C_QACKD (Reason=1000 OOOO2): Call is queued because the resource is in use at the moment. The MS 

shall wait TP_Timer for further signalling and may indicate a possible delay to the calling MS. The MS 
may choose to differentiate between 1), 2) and 3) by providing the calling MS with a particular 
indication for each of the conditions. 

b) Termination PDUs are selected from an appropriate Reason information element in a C_NACKD PDU (see 
clause 7.2.8): 

1) C_NACKD: Call refused and terminated. The C_NACKD PDU provides a versatile range of Reason 
codes to indicate to the calling party why the Service request was terminated. The calling party shall 
return to the idle state. 
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6.6.3.2.5 Availability Check to the called MS (packet data) 

For an individual MS address call set-up, the called MS shall receive a radio check to which it will respond with an 
appropriate acknowledgement. 



• 



• 



The called party shall respond C_NACKU, if it cannot accept the call or its data terminal equipment is not 
ready (the TSCC shall send an appropriate call failed response to the calling MS). 

The calling party shall respond C_ACKU (Reason=Message_Accepted), if the call is accepted (the TSCC shall 
progress the service request and allocate a payload channel by transmitting appropriate Channel Grant PDUs). 



6.6.3.2.6 Payload Channel Allocation 

MS shall check the address information elements received in Packet Data Channel Grant PDUs. If it is determined that 
the Channel Grant PDU is applicable then it shall retune to the indicated physical/logical payload channel to commence 
the Packet Data Service. 

a) For Private Packet Data Channel Grant CSBK PDU: 

1) If an MS receives a Private Channel Grant PDU where either the Source Address or the Target Address 
information element matches its individual address then that PDU is applicable. 

b) Talkgroup Packet Data Channel Grant CSBK PDU: 

1) If an MS receives a Talkgroup Channel Grant PDU with the Target Address information element 
matching one of its talkgroup addresses then that PDU is applicable. 



2) If an MS receives a Talkgroup Channel Grant PDU with the Source Address matching its individual 
address then that PDU is applicable. 

6.6.3.3 Procedures for the Packet Data Payload Channel 

MSs are directed to a Packet Data payload physical/logical channel on the TSCC. When the Packet Data call is 
terminated by either the TS or MS, the MS shall return to the TSCC. When a physical channel has been assigned, data 
PDUs of arbitrary length are transferred over the DMR Air Interface using the packet technique described in 
TS 102 361-1 [5] andTS 102 361-3 [7]. 

A Packet Data call may continue unless the call is terminated by a) the MS or b) the TS or c) terminated prematurely as 
a result of the expiry of an overall payload call payload timer). 

A physical channel may be configured such that two independent payload channels are available to the system (single 
slot transmission mode) or a high-speed data mode (dual slot transmission mode) where both logical channels are 
combined to provide a high-speed Packet Data service. The particular data speed configuration is requested by the 
calling MS and signalled to the parties by the Channel Grant PDUs. 

The procedures for TS/MS behaviour on the Packet Data payload channel are described in TS 102 361-3 [7]. In the 
trunked environment however, additional call maintenance PDUs are exchanged between MS and TS in addition to the 
PDUs described in TS 102 361-3 [7]. 

When active on a payload channel shall transmit the CACH in the same form as described in TS 102 361-2 [6], 
clause 7.1.3.2). 

The system may direct a number of independent Packet Data calls to the same Packet Data channel. MSs may then 
share that channel, but it must be noted that while MS are away from the TSCC, they are unable to receive new calls. 
New Packet Data calls directed to a MS that is active on a Packet Data channel may either be queued by the system or 
such a call may be directed to the Packet Data channel and share the channel with other ongoing calls. 

If the destination is an ipv4 or ipv6 address, the destination address will have been specified by the calling party as a 
function of a multi-part call set-up. Therefore the when the MS is directed to the packet data payload channel the system 
will have the full destination address. The MS may therefore set the destination address to IPI for all packet data items. 

If an MS receives a packet data call set-up from an ipv4 or ipv6 address, the UDT protocol is able to send the full 
calling party IP address as part of the call set-up using the supplementary data transfer service. The system may then use 
IPI as the source address for the packet data call. 
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6.6.3.3.1 



TS Procedures for the Packet Data Payload Channel 



If a new physical channel is allocated on the TSCC, the CCL_BS shall start both the CCL_1 and CCL_2 processes as 
described in TS 102 361-2 [6], clause 5.1.1.1.3) and start the Packet Data payload timer T_PACKET_TIMER. 



6.6.3.3.1.1 



MS radio check 



The TS may poll an individual MS to check if the MS is active on the payload channel by transmitting a P_AHOY PDU 
with the information elements set as follows. 

The TSCC transmits a P_AHOY with the information elements as shown in table 6.32. 

Table 6.32: P AHOY information elements for Packet Data service individual radio check 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


O2 


Reserved 


2 


OO2 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Individual Packet Call Service - 001 O2 


Target address 


24 


Individual Address of Called MS 


Source Address or Gateway 


24 


TSI 



The response is C_ACKU (Reason=Message_ Accepted). 

The TS may also poll a talkgroup to check if at least one member of the talkgroup is active on the payload channel by 
transmitting a P_AHOY PDU with the information elements set as follows. 

The TSCC transmits a P_AHOY with the information elements as shown in table 6.33. 

Table 6.33: P_AHOY information elements for packet service talkgroup radio check 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


O2 


Reserved 


2 


OO2 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Talkgroup Packet Call Service - OOII2 


Target address 


24 


Address of the talkgroup 


Source Address or Gateway 


24 


TSI 



The response is P_ACKU (Reason=Message_ Accepted). If more than one MS makes a response to this PDU, it is likely 
that the TS will be unable to decode it because of collisions. The purpose of this procedure is to determine if any 
talkgroups are active therefore the TS may use the presence of the burst for the result of the talkgroup radio check. 



6.6.3.3.1.2 



Authentication Check 



The authentication procedures are identical to the authentication procedures described in clause 6.4.8.2 but with the 
C_AHOY PDU replaced by a P_AHOY PDU. 



6.6.3.3.1.3 



Disabling/enabling a users transmission 



The TS may at any time send a P_PROTECT (Protect_Kind=DIS_PTT) addressed to an individual MS, talkgroup, or 
All Unit ID to disable all MS transmissions for the remainder of the call. Since the P_PROTECT PDU is 
unacknowledged the PDU may be repeated. 

The TS may also at any time send a P_PROTECT (Protect_Kind=EN_PTT) addressed to an individual MS, talkgroup, 
or All Unit ID to enable the users transmission. Since the P_PROTECT PDU is unacknowledged the PDU may be 
repeated at layer 2. 
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6.6.3.3.1.4 



Swapping the call to a replacement Packet Data payload channel 



The TS may send Channel Grant PDUs to move MS already active to an alternative packet data payload channel. If MS 
had previously received a P_PROTECT to disable its transmissions, the transmissions shall be re-enabled on the 
replacement packet data payload channel. The replacement packet data channel shall be with the same slot 
configuration (single or dual slot). If the packet data payload channel supports multiple simultaneous calls then channel 
grant PDUs must be transmitted for each of the MS or talkgroups currently active on the payload channel. 

6.6.3.3.1 .5 Clearing down the packet data channel 
The TS shall clear down the parties involved in all payload calls if: 

a) the relevant overall payload call timer T_PACKET_TIMER expires; 

b) the TS receives a P_MAINT (Maint_Kind = DISCON) PDU; 

c) the TS detects by any other means that the call has ended (e.g. PSTN destination on hook); 

d) the TV_Hangtime interval timer expires. 

The TS shall clear down the data call by transmitting P_CLEAR PDU(s). Since this PDU is not acknowledged it may be 
repeated at layer 2. 

6.6.3.3.1 .6 Clearing down a particular MS or talkgroup 
The TS is able to clear down the parties involved in a payload call if: 

a) the TS receives a P_MAINT (Maint_Kind = DISCON) PDU; 

b) the TS detects by any other means that the packet call has ended. 

The TS response to an appHcable P_MAINT(Maint_Kind-DISCON) is P_NACKD. 

The TS may selectively clear a MS by transmitting a P_AHOY with information elements set as table 6.34. 

Table 6.34: P_AHOY information elements to clear an individual MS from a packet payload channel 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


O2 Indicates that the target is an Individual Address 


Reserved 


2 


OO2 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Cancel Call Service - 1 1 1 12 


Target address 


24 


Individual Address of MS 


Source Address or Gateway 


24 


TSI 



The permitted response is P_ACKU (Message_ Accepted). 

The TS may selectively clear a talkgroup by transmitting a P_AHOY with information elements set as table 6.35. 

Table 6.35: P_AHOY information elements to clear a talkgroup from a packet payload channel 



Service_Options_Mirror 


7 


000 OOOO2 


Service_Kind_Flag 


1 


^2 Indicates that the target is a talkgroup 


Reserved 


2 


OO2 


Appended_Blocks 


2 


OO2 


Service_Kind 


4 


Cancel Call Service - 1 1 1 12 


Target address 


24 


talkgroup 


Source Address or Gateway 


24 


TSI 



The permitted response is P_ACKU (Message_ Accepted). 
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6.6.3.3.2 MS Procedures for the Packet Data Payload Channel 

6.6.3.3.2.1 MS receives an MS radio check 

If an MS receives a P_AHOY to its individual address with information elements set as table 6.34, then it shall respond 
with a P_ACKU (Reason=message_accepted). 

If an MS receives a P_AHOY to it is the talkgroup address previously transmitted in the Channel Grant PDU that 
directed this MS to the payload channel (information elements set as table 6.35) then it shall respond with a P_ACKU 
(Reason=message_accepted). 

6.6.3.3.2.2 MS receives a Authentication Check Challenge 

The authentication procedures are identical to the authentication procedures described in clause 6.4.8.2 but with the 
authentication response C_ACKU PDU replaced by a P_ACKU PDU. 

6.6.3.3.2.3 Disabling/enabling a user transmission 

If the MS receives a P_PROTECT (Protect_Kind=DIS_PTT) addressed to its individual address, or to it is talkgroup 
address previously transmitted in the Channel Grant PDU, or All Unit ID, the MS shall disable it is transmissions. 

If the MS receives a P_PROTECT (Protect_Kind=EN_PTT) addressed to its individual address, to it is talkgroup 
address previously transmitted in the Channel Grant PDU, or All Unit ID, the MS shall re-enable it is transmissions. 

6.6.3.3.2.4 MS receives a Channel Grant PDU(s) 

If a MS receives an applicable Channel Grant addressed to its individual address or to it is talkgroup address previously 
transmitted in the Channel Grant PDU, then it shall retune to the designated physical/logical channel. If the PTT was 
disabled prior to receiving the Channel Grant, the PTT shall be re-enabled unless this MS was the recipient of a 
broadcast call set-up or a call to All-Unit ID. 

6.6.3.3.2.5 End of call 

The MS shall signify the end off the call by transmitting a number of P_MAINT (Maint_Kind = DISCON). The MS 
shall send the P_MAINT PDUs consecutively then return to the control channel acquisition procedures (it is suggested 
that the TSCC initially sampled is the TSCC that transferred the call to the payload channel). 

6.6.3.3.2.6 MS receives P_CLEAR 

If a MS receives a P_CLEAR PDU then it shall abandon the payload channel and move to the TSCC indicated by the 
Logical Physical Channel Number PDU. 

6.6.3.3.2.7 MS receives a selective clear P_AHOY 

If a MS receives an individually addressed P_AHOY, Service_Kind=llll2, Service_Kind_Flag=02 information 
element then it shall send a P_ACKU (Reason=Message_Accepted), abandon the payload channel and return to the 
control channel acquisition procedures (it is suggested that the TSCC initially sampled is the TSCC that transferred the 
call to the payload channel). 

If a MS receives a P_AHOY, Service_Kind=l 1 1 12, Service_Kind_Flag=l2 information element addressed to it is 
talkgroup address previously transmitted in the Channel Grant PDU the talkgroup then it shall send a P_ACKU 
(Reason=Message_Accepted) abandon the payload channel and return to the control channel acquisition procedures (it 
is suggested that the TSCC initially sampled is the TSCC that transferred the call to the payload channel). 
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6.6.3.3.2.8 Time out on the Payload Channel 

A MS shall maintain a number of timers while active on a packet data payload channel. 

a) Inactivity timer: 

A MS shall measure the length of time the MS is unable to detect adequate signal quality. If the MS fails 
to detect adequate signal quality for a continuous time TDJnactive, the MS shall assume that the call has 
ended and return to the control channel acquisition procedures without sending any call termination 
signalling (it is suggested that the TSCC sampled is the TSCC that transferred the call to the payload 
channel). 

b) Item Duration timer: 

A MS shall maintain the maximum item duration timer TD_Item. If the MS reaches the maximum item 
duration TD_Item, the MS shall transmit a Terminator with LC, discontinue the item and indicate to the 
higher layers that the item was not successfully transmitted. 

c) An overall payload call timer: 

If the overall packet data payload call timer T_PACKET_TIMER expires, the MS shall transmit a 
number(N_Maint) of P_MAINT PDUs consecutively then return to the control channel acquisition 
procedures (it is suggested that the TSCC sampled is the TSCC that transferred the call to the payload 
channel) If the MS was sending speech frames when the overall data packet payload call timer expires, 
the MS shall transmit a Terminator with LC prior to transmitting the P_MAINT PDUs. 



6.6.4 Short Data Message Procedure 



The Short Data Message service enables data to be transmitted between DMR entities using the control channel. Up to 
462 bits of data may be transported using this service formatted in a number of formats including binary, BCD, 7 bit 
text, 8 bit characters, NMEA (lEC 61162-1 [8]), Unicode, IP, authentication and manufacturer specific proprietary 
formats. 

The Short Data Message procedure uses the multi-part call set-up. A MS may send a Short Data Message to an MS, a 
talkgroup, the PSTN or PABX, a line connected gateway, a dispatcher gateway, or all MS (if the TSCC permits it). The 
TSCC may also transmit a short data message from a gateway addressed to an individual MS or talkgroup. 
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Figure 6.40: Example of a Short Data Message transfer 

Figure 6.40 shows an example of a short data message transfer from MS to MS: 

a) MS (A) calculates the number of appended UDTs needed to transmit the short data. In this example, two 
appended UDTs are required; 

b) "A" is the random access C_RAND PDU. The called party is MS(B) and Service_Kind set to 'Short Data' and 
the Appended_Short_Data PDU to the number of data blocks needed to transport the short data; 

c) "B" is a C_AHOY PDU that request MS(A) to transport the short data using the UDT mechanism; 

d) "C" is the inbound phase consisting of a Multi-block UDT header + appended data; 
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e) "D" is the outbound phase consisting of a Multi-block UDT header + appended data; 

f) "E" is the acknowledgement from MS(B); 

g) "F" is the final acknowledgement to the calling party MS (A). Note that the acknowledgement is repeated for 
reliability. 

For a call to an extended address destination the TSCC uses the UDT mechanism to transport the extended address 
information. In this case the inbound phase will use two UDT procedures. The PDUs in the C_AHOY PDU indicate 
which UDT inbound transport is requested by unambiguous PDUs in the C_AHOY PDU. 

The maximum number of bits that may be transported by the short data message service is limited by the maximum 
number of appended data UDTs. The tier III protocol permits up to four appended UDTs. 

For a short data message service to a talkgroup, the called party shall not send a response. The TSCC may repeat the 
outbound phase to improve the probability of a successful message transfer. The TSCC shall send a final 
acknowledgement to the calling unit even though the receipt of the short data message is not certain. 

The timing for the inbound and outbound phases is not prescribed in the present document. Figure 6.26 shows examples 
of other applicable short data message delivery. 

In the first example, the UDT Header and appended UDTs are re-transmitted by the TSCC as soon as they have been 
received. This timing has the advantage of minimizing end-to-end latency (between two subscriber units); however, 
messages received with detectable but uncorrectable errors on the inbound phase result in messages containing 
uncorrectable errors on the downlink which is essentially wasted bandwidth. The whole uplink and downlink phase 
would have to be repeated. 

If the inbound phase is completed in its entirety as shown in the second example (and in figure 6.40), if uncorrectable 
errors are detected, that phase may be repeated before moving to the outbound phase. However, end-to-end latency 
(between the two MS) is sacrificed. 
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Figure 6.41 : More Examples of a Short Data Message transfer 



6.6.4.1 



Short Data Procedures for the TSCC 



A MS requests a tier III short data message service by generating a random access request PDU with the Target Address 
set to: 

a) an individual MS address; 

b) a talkgroup MS address; 

c) a gateway address (a UDT to transport the extended destination address from the MS). 
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When the TSCC responds to the random access request, it shall start a timer (TNP_Timer). This timer shall be refreshed 
if the TSCC sends further call progress messages to the calling party. 



6.6.4.1.1 



TSCC Response to a call to an individual MS or talkgroup 



When a random access short message service PDU is received on the TSCC, the TSCC shall send a response in 
accordance with the random access procedures prescribed in clause 6.2. 

The PDUs that represent a valid response to the short data message service random access request to a MS or talkgroup 
are: 

a) an acknowledgement PDU C_NACKD, C_QACKD, C_WACKD; 

b) a UDT Head + appended block(s) (short data call is diverted); 

c) a C_AHOY PDU instructing the calling MS to transport its short data message using the UDT mechanism; 

d) a C_AHOY PDU instructing the calling MS to transport supplementary data using the UDT mechanism; 

e) for a call to an extended address, A C_AHOY PDU instructing the calling party to send its extended address 
(such as PSTN, PABX etc) using the UDT mechanism. 

NOTE: c), d) and e) may be performed in any order. 



6.6.4.1.2 



TSCC Response to a call to an extended address destination 



When a random access short message service PDU is received on the TSCC, the TSCC shall send a response in 
accordance with the random access procedures prescribed in clause 6.2. 

The PDUs that represent a valid response to the short data message service random access request to an extended 
address are: 

a) an acknowledgement PDU C_QACKD, C_WACKD; 

b) a C_AHOY PDU instructing the calling MS to transport its short data message using the UDT mechanism; 

c) a C_AHOY PDU instructing the calling MS to transport supplementary data using the UDT mechanism; 
NOTE: b) and c) may be performed in any order. 

The gateway PDUs for C_AHOY PDUs to support short data message services are prescribed in table 6.36. 

Table 6.36: C_AHOY information elements for short data message service to a gateway 



Action 


Gateway 
Address 


Remark 


Send PSTN digits for the short data destination 


PSTNI 


The calling party shall uplink BCD dialled digits 


Send PABX digits for the short data destination 


PABXI 


The calling party shall uplink BCD dialled digits 


Uplink IP address for the short data destination 


IPI 


The calling party shall uplink the IPV4 or IPV6 address 



d) C_NACKD: Call refused and terminated. The calling party shall return to the idle state; 



e) if the TS has previously accepted a call diversion indicating that this type of service request be directed to 
another called party, a UDT Head + Appended data indicating the diverted address. 



6.6.4.1.3 



Availability Check to the called MS (short data) 



For calls to individual MS, the TSCC may check that the called party is in radio contact before downloading the short 
data. 

The TSCC may check availability of the called party by: 

a) Sending a C_AHOY PDU to that called party. 
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b) Sending a Multi-block UDT with supplementary data (if the supplementary data service is active for this call). 
If a response is not received from the calling party the TSCC may repeat the C_AHOY. 
The availability check demands a response from the called party: 

• If the response is C_NACKU, the TSCC shall abandon the short message call send an appropriate call failed 
response to the calling MS and echo the Reason in the C_NACKD PDU. 

• If the response is C_ACKU (Reason=Message_Accepted), the TSCC shall progress the service request and 
download the short data message using the UDT mechanism. 



6.6.4.1.4 



Final acknowledgement to the calling party 



In the outbound phase, the TSCC downloads the short data message to the called party. If the recipient is an individual 
MS an acknowledgement shall be received on the TSCC. For a short data message service to a talkgroup the outbound 
phase may be repeated but no acknowledgement shall be expected. 

The TSCC shall send an appropriate acknowledgement to the calling party to indicate the outcome of the short data 
transfer request. 



6.6.4.2 



Short Data Message procedures for MS 



A MS requests a short data message call service to another individual MS or a talkgroup or gateway using a multi-part 
service request. For calls to an extended address the transport of the extended address and the short data message is 
uploaded by two separate UDT transfers. 

A MS requests a short data service by sending a C_RAND random access request complying with the random access 
procedures in clause 6.2. The PDUs in the random access request are passed to the CC layer - set appropriately as 
prescribed in table 6.37. 

Table 6.37: C_RAND information elements for a Short Data Message Service 



Information 
Element (I.E) 


I.E 
Length 


length 


Alias 


Value 


Remark 


Service_Options 


7 


1 


EMERG 


Not applicable - O2 


1 




O2 


Privacy (see note 1 ) 


1 


SUPED_SV 


O2 


No Supplementary Data Transfer Service 
required for this call 


I2 


Supplementary Data Transfer Service 
requested for this call 


1 


BCAST_SV 


O2 


Not applicable - O2 


1 


OVCM_SV 


O2 


Not applicable - O2 


2 


PRIORTY_SV 


O2 


Not applicable - O2 


Proxy Flag 


1 




PROXY 


O2 


Number of Extended BCD digits for 
addressing through a gateway = 1 to 20 


I2 


Number of Extended BCD digits for 
addressing through a gateway = 21 to 44 


Appended_Supplem 
entary Data 


2 




SUPED_VAL 


Value 


Number of appended UDTs required to 
transport supplementary data 


Appended_Short 
Data 


2 




SDATA_VAL 


OO2 


Number of appended UDTs required 
transport short data 


Service_Kind 


4 




IND_SD_SRV 


OIOO2 


Individual Short Data Gall Service 


GRP_SD_SRV 


OIOI2 


Talkgroup Short Data Call Service 


Target_address or 
Gateway 


24 






Value 


Target Address (see note 2) 


Source address 


24 






Value 


Individual Address of the requesting MS 


NOTE 1 : Privacy is not defined in the present document. 

NOTE 2: If Service_Kind = IND_SD_SRV then Target_Address represents an Individual address. 
If Service Kind = GRP SD SRV then Target Address represents a Talkgroup. 
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6.6.4.3 Initiating a Short Data Message service 

For a short data message service request to an individual MS or talkgroup, the destination address is completely 
expressed by the Target Address information element in the C_RAND random access PDU. The Service_Kind specifies 
if the Short Data Message call service is addressed to an individual address or a talkgroup. For calls to a gateway 
addresses the Target_address or Gateway information element in the C_RAND is set to the gateway address. 

The MS shall attempt access until it receives a valid response, or the service is cancelled by the user, or the attempt fails 
by sending the maximum number of random access PDUs or the random access timer expires. 

6.6.4.4 Response to a random access short data message 

The calling MS shall accept the following PDUs a valid response to the SDM random access request: 

a) an acknowledgement PDU C_NACKD, C_QACKD, C_WACKD; 

b) a UDT Head + appended block(s) (short data call is diverted); 

c) a C_AHOY PDU instructing the calling MS to transport its short data message using the UDT mechanism; 

d) a C_AHOY PDU instructing the calling MS to transport supplementary data using the UDT mechanism; 

e) for a call to an extended address, A C_AHOY PDU instructing the calling party to send its extended address 
using the UDT mechanism. 

NOTE: c), d) and e) may be performed in any order. 

6.6.4.5 Acknowledgements received by the calling MS 

When the C_RAND PDU has been transmitted by the calling party, an initial response may be received by the calling 
party as specified in clause 6.6.4.4. 

At any time further PDUs may be sent to the calling party as follows: 

a) a C_NACKD at any time to indicate the call has failed. The Reason information element shall be set to 
indicate the reason for the call failure; 

b) a C_WACKD if more signalling will follow; 

c) after the short data message has been successfully transported, C_ACKD PDU. 

If a C_NACKD is received, the calling MS shall abandon the short data message call and return to the idle state. 
Any applicable call progress acknowledgement received shall restart the TNP_timer. 

6.6.4.6 Timeout waiting for further signalling 

A MS waiting for further signalling shall abandon the short data message service and return to the idle state if the 
TNP_Timer expires. 

6.6.4.7 MS receiving a short data message 



If a MS receives a multi block UDT Head PDU with the Target Address matching its individual address, it shall 
respond with an appropriate acknowledgement. The Appended_B locks information element in the UDT header 
indicates the number of appended UDT blocks. 

If a MS receives a multi block UDT Head PDU with the Target Address matching a talkgroup, it shall accept the 
information contained in the appended blocks, but shall transmit no response. 
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6.6.4.8 Short Data Message procedure MSC 

Figure 6.42 illustrates the Short Data Message procedure to an individual MS or Talkgroup as defined in clause 6.6.4. 
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Figure 6.42: Short Data Message MSC 

6.6.5 Short Data Polling Service 

The Short Data Polling Message service enables data to be polled from MS using the control channel. Up to 288 bits of 
data may be transported using this service formatted in a number of formats including binary, BCD, ISO 7 bit text 
(ISO/IEC 646 [11]), ISO 8 bit characters (ISO/IEC 8859 [12]), NMEA (lEC 61162-1 [8]) formatted location data, and 
manufacturer specific proprietary formats. 

NOTE: Calling and polled MSs must pre-arrange the number of appended UDTs required to transport the polled 
data. 
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The Short Data Message polling procedure uses the single-part call set-up. 
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Figure 6.43: Example of a Short Data Polling transfer 

Figure 6.43 shows an example of a short data polling service: 

a) MS (A) specifies the number of appended UDTs for the polled short data. In this example, one appended UDT 
is required; 

b) "A" is the random access C_RAND PDU. The target address is set to the polled party, Service_Kind set to 
'Short Data Polling' and the Appended_Short_Data information element to the number of data blocks to 
transport the polled short data; 

c) "B" is a C_AHOY PDU that requests MS(B) to transport the short data using the UDT mechanism; 

d) "C" is the inbound phase consisting of a Multi-block UDT header + appended data; 

e) "D" is the outbound phase consisting of a Multi-block UDT header + appended data; 

f) "E" is the final acknowledgement from MS(A). 

The maximum number of bits that may be transported by the short data message polling service is limited by the 
maximum number of appended data UDTs. The tier III protocol permits up to four appended UDTs. 
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Figure 6.44: Example of short data polling from a gateway 

Figure 6.44 shows a short data polling transfer from a gateway to a MS. The TSCC requests the short data by 
transmitting a C_AHOY PDU addressed to MS(A). MS(A) responds with the UDT head + short data. 



6.6.5.1 



Short Data Polling Procedures for the TSCC 



A MS requests a tier III short data polling message service by generating a random access request PDU with the Target 
Address set to an individual address. 

When the TSCC responds to the random access request, it shall start a timer (TNP_Timer). This timer shall be refreshed 
if the TSCC sends further call progress PDUs to the calling party. 
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6.6.5.1 .1 TSCC Response to a poll request from an MS 

When a random access short data poll service PDU is received on the TSCC, the TSCC shall send a response in 
accordance with the random access procedures prescribed in clause 6.2. 

The PDUs that represent a valid response to the short data polling service random access request to a MS or talkgroup 
are: 

a) an acknowledgement PDU C_NACKD, C_QACKD, C_WACKD; 

b) a C_AHOY PDU instructing the polled MS to transport supplementary data using the UDT mechanism. 
NOTE: If the polled MS has diverted its calls the response shall be C_NACKD (Reason^ Div_Cause_Fail). 

6.6.5.1 .2 Availability Check to the called MS (short data poll) 

The TSCC may check that the called party is in radio contact before polling the MS for the short data. 

The TSCC may check availability of the polled party by sending a C_AHOY PDU addressed to the polled MS 
individual address. If a response is not received from the calling party the TSCC may repeat the C_AHOY at layer 2. 

The availability check demands a response from the called party: 

a) If the response is C_NACKU, the TSCC shall abandon the short message polling transaction, send an 
appropriate call failed response to the calling MS and echo the Reason in the C_NACKU PDU. 

b) If the response is C_ACKU (Reason=Message_Accepted), the TSCC shall progress the service request and 
poll the MS for the short data using the UDT mechanism. 

6.6.5.1 .3 Delivery of the polled data to the calling party 

In the outbound phase, the TSCC downloads the short data polled message to the calling party using the UDT 
mechanism. 

The calling MS shall send an appropriate acknowledgement to the TSCC to indicate the outcome of the short data 
polling request. 

6.6.5.1 .4 Final acknowledgement by the calling party to the TSCC 

The final phase of the polling transaction is the acknowledgement from the calling MS that the polled data was 
successfully received. If the TSCC does not receive a response, it may repeat the outbound phase described in 
clause 6.6.5.1.3. 

6.6.5.1 .5 Short Data Polling procedures from a TSCC gateway 

The short polling service initiated through a gateway is illustrated in figure 6.44. The TSCC transmits a C_AHOY PDU 
addressed to an individual MS. The C_AHOY PDU demands a response: 

a) If the response is C_NACKU, the TSCC shall abandon the short message polling transaction. 

b) If the response is a multi-block UDT containing the polled data, the transaction is complete. 

6.6.5.2 Short Data Polling Message procedures for MS 

A MS requests a short data polling call service to another individual MS, using a single-part service request. 

A MS requests a short data service by sending a C_RAND random access request complying with the random access 
procedures in clause 6.2. The information elements in the random access request are passed to the CC layer - set 
appropriately as prescribed in table 6.38. 
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Table 6.38: C_RAND information elements for a Short Data Polling Service 



Information 
Element (I.E) 


I.E 
Length 


length 


Alias 


Value 


Remark 


Service_Options 


7 


1 


EMERG 


Not applicable - O2 


1 




02 


Privacy (see note) 


1 


SUPED_SV 


02 


Not applicable - O2 


4 


POL FMT 


Value 


Format of the polled data 


Proxy Flag 


1 




PROXY 


O2 


Not Defined for the polling service 


Appended_Supplem 
entary Data 


2 




SUPED_VAL 


OO2 


Not Defined for the polling service 


Appended_Short_ 
Data 


2 




SDATA_VAL 


OO2 


Number of UDTs required to transport the 
polled short data 


Service_Kind 


4 




SD_P_SRV 


011 O2 


Short Data Polling Service 


Target_address 


24 






Value 


Polled individual MS address 


Source address 


24 






Value 


Individual Address of the requesting MS 


NOTE: Privacy is not defined in the present document. 



6.6.5.3 Initiating a Short Data Polling service 

For a short data polling service request to an individual MS, the polling MS address is completely expressed by the 
Target Address information element in the C_RAND random access PDU. The Service_Kind specifies the Short Data 
Message call service. 

The MS shall attempt access until it receives a valid response, or the service is cancelled by the user, or the attempt fails 
by sending the maximum number of random access PDUs or the random access timer expires. 

6.6.5.4 Response to a random access short data polling message 

The calling MS shall accept the following PDUs a valid response to the SDM random access request: 

a) An acknowledgement PDU C_NACKD, C_QACKD, C_WACKD. 

b) A C_AHOY PDU instructing the polled MS to transport its short data message using the UDT mechanism. 

6.6.5.5 Final Acknowledgement transmitted by the calling MS 

In the outbound phase, the TSCC downloads the short data polled message to the calling party. Valid responses to the 
TSCC are: 

a) An acknowledgement PDU C_NACKU indicating the transaction has failed. 

b) An acknowledgement PDU C_ACKU indicating the transaction was successful. 



6.6.5.6 



Timeout waiting for further signalling 



A MS waiting for further signalling shall abandon the short data polling service and return to the idle state if the 
TNP_Timer expires. 



6.6.5.7 



MS receiving a C_AHOY poll for a short polling message 



If a MS receives a C_AHOY PDU with the Target Address matching its individual address and the 
Service_Kind = Short Data Polling Service it shall respond with: 



a) A multi block UDT Head PDU with the Target Address matching its calling party (source) address from the 
C_AHOY PDU. The Appended_B locks information element in the UDT header indicates the number of 
appended UDT blocks. 

b) A C_NACKU PDU if the polled MS does not wish to accept the polling request. 
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6.6.6 Status Call Service 



The Status Message service enables data to be transmitted between DMR entities on the control channel. Seven bits of 
data may be transported using this service. The status delivery service transports a status message from the initiator to a 
recipient. The status polling service enables an initiator to request a status message from an addressed entity. Seven bits 
are transported representing 128 status messages. Each status message has a user-defined meaning. 

Status message addressed from MS to the TSSC are system messages. 

6.6.6.1 Status Service Delivery Procedure 

The Status Message procedure employs a store and forward mechanism. An MS may send a Status Message to an 
individual MS, the PSTN or PABX, a line connected gateway, a dispatcher gateway or the TSCC. The TSCC may also 
transmit a short data message from a gateway or special identifier addressed to an individual MS. 

6.6.6.1 .1 Status Service Delivery Procedures for the TSCC 

A MS initiates a Status Service by random access addressed to: 

a) An individual MS address (single-part call set-up). 

b) A gateway address that indicates a multi-part call set-up. 

c) The TSCC. 

When the TSCC responds to the random access request it shall start timer (TNP_Timer). This timer shall be refreshed if 
the TSCC sends further call progress messages to the calling party. 

6.6.6.1 .1 .1 TSCC Response to a single part Status Service Delivery call setup 
On receipt of the random access service request the TSCC shall transmit either: 

a) An acknowledgement PDU C_NACKD, C_WACKD (Reason=Wait), C_ACKD addressed to the calling MS. 

b) A C_AHOY PDU addressed to the called party for this call to pass the status to the called MS. 

c) A UDT Head _ appended block(s) (status message service is diverted. If the TS has previously accepted a call 
diversion indicating that this type of service request be directed to another called party, the TSCC shall invoke 
the UDT and send a UDT Head + Appended data to the calling party. 

6.6.6.1 .1 .2 TSCC Response to a multi part Status Service Delivery call setup 

For calls to extended addresses, the MS requests multi-part addressing by generating a status call random access request 
with the Destination Address information element set to a gateway address (PABXI, PSTNI, etc) and the Proxy Flag 
information element to indicate the number of digits for the extended address. For the number of dialled digits = 1 to 20 
the Proxy Flag information element shall be set to O2. For the number of dialled digits = 21 to 44 the Proxy Flag 
information element shall be set to I2. The PDUs that shall represent a valid response to the multi-part part Status 
service random access request are: 

a) An acknowledgement PDU C_NACKD, C_WACKD(reason=Wait). 

b) A C_AHOY PDU for the calling MS to send the extended address information. 

c) A C_AHOY PDU for the calling MS to send supplementary data (see clause 6.5). 

For b) The TSCC shall then invoke the UDT procedure by sending a C_AHOY to the calling MS to send the extended 
address information. For a call to the PABX or PSTN the extended address information shall be BCD digits. The Proxy 
Flag information element in the C-AHOY PDU shall be copied from the Proxy Flag information element received from 
the MS C_RAND PDU. If the TSCC does not successfully receive the UDT from the MS, the TSCC may repeat the 
C_AHOY, or transmit a C_NACKD to indicate failure of the call. 



ETSI 



1 1 5 ETSI TS 1 02 361 -4 V1 .2.1 (2006-09) 

For c) The TSCC shall then invoke the UDT procedure by sending a C_AHOY to the calling MS to send the 
supplementary data. The format of the supplementary data is specified in the UDT. If the TSCC does not successfully 
receive the UDT from the MS, the TSCC may repeat the C_AHOY, transmit a C_NACKD to indicate failure of the call 
or continue with the call setup and abandon the supplementary data. 

6.6.6.1 .1 .3 Acknowledgements sent on the TSCC to the calling MS (status) 

The TSCC may send acknowledgement PDUs following the random access Status service request to indicate the 
progress of the call, or terminate the call. If the TSCC sends a PDU to indicate the progress of a call it shall start a 
waiting timer TNP_Timer. (The calling party MS maintains a similar timer). 

a) Progress PDUs may be: 

1) C_WACKD: Intermediate acknowledgement. More PDUs to follow. 

2) C_QACKD: Called MS engaged in another call. 

3) C_QACKD: Call is queued because the resource is in use at the moment. 

b) Termination PDUs are selected from an appropriate Reason information element in a C_NACKD PDU (see 
clause 7.2.8): 

1) C_NACKD. 

6.6.6.1 .1 .4 Delivery of the status to the called party 

The TSCC delivers the status to the called MS by transmitting a C_AHOY PDU containing the Status information 
element. The status message may have originated from another MS, a gateway or the TSCC. The C_AHOY PDU 
demands a response from the called MS. If the response is C_ACKU or C_NACKU, the TSCC shall send an equivalent 
acknowledgement to the calling party. If no response is received the TSCC may repeat the C_AHOY or abandon the 
service and indicate the failure to the called party by transmitting a C_NACKD. 

6.6.6.1.1.5 CallTimeOut 

The TSCC shall maintain a timeout defining the maximum time it shall store a status message request waiting for the 
called MS or TSCC resource to become free. 

6.6.6.1 .2 Status Service Delivery Procedures for MS 

A MS requests a status message call service to another individual MS using a single part service request or gateway 
using a multi-part service request. For calls to an extended address the sending of the extended address is by a UDT 
transfer. 

A MS requests a status service by sending a C_RAND random access request complying with the random access 
procedures in clause 6.2. The information elements in the random access request are passed to the CC layer - set 
appropriately as prescribed in table 6.39. 
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Table 6.39: C_RAND information elements for a Status Message Service 



Information 
Element (I.E) 


I.E 
Length 


length 


Alias 


Value 


Remark 


Service_Options 


7 




STATUS 


value 




Proxy Flag 


1 




PROXY 


02 


Number of Extended BCD digits for 
addressing through a gateway = 1 to 20 


I2 


Number of Extended BCD digits for 
addressing through a gateway = 21 to 44 


Appended_Supplem 
entary_Data 


2 




SUPED_VAL 


Value 


Number of appended UDTs required to 
transport supplementary data 


Appended_Short_ 
Data 


2 




SDATA_VAL 


OO2 


Not Defined for the status Service 


Service_Kind 


4 




IND_ST_SRV 


OIII2 


Status Transport Service 


Target_address or 
Gateway 


24 






Value 


Target Address (see note 2) 


Source address 


24 






Value 


Individual Address of the requesting MS 


NOTE 1 : Privacy is not defined in the present document. 

NOTE 2: Target_Address represents an Individual address or gateway. 



6.6.6.1.2.1 



Initiating a Status Message service 



For a status message service request to an individual MS, the destination address is completely expressed by the Target 
Address information element in the C_RAND random access PDU. The Service_Kind specifies the Status Message call 
service. For calls to a gateway addresses the Target_address or Gateway information element in the C_RAND is set to 
the gateway address. 

The MS shall attempt access until it receives a valid response, or the service is cancelled by the user, or the attempt fails 
by sending the maximum number of random access PDUs or the random access timer expires. 

6.6.6.1 .2.2 Response to a random access status message service request 

The calling MS shall accept the following PDUs a valid response to the status service random access request: 

a) An acknowledgement PDU C_NACKD, C_QACKD, C_WACKD. 

b) A UDT Head + appended block(s) (short data call is diverted). 

c) A C_AHOY PDU to the called MS containing the status PDU. 

d) A C_AHOY PDU instructing the calling MS to transport supplementary data using the UDT mechanism. 

e) For a call to an extended address, A C_AHOY PDU instructing the calling party to send its extended address 
using the UDT mechanism. 

NOTE: d) and e) may be performed in any order. 

6.6.6.1 .2.3 Acknowledgements received by the calling MS 

When the C_RAND PDU has been transmitted by the calling party, an initial response may be received by the calling 
party as specified in clause 6.6.6.1.1.3. 

At any time further PDUs may be sent to the calling party as follows: 

a) A C_NACKD at any time to indicate the call has failed. The Reason information element shall be set to 
indicate the reason for the call failure. 

b) A C_WACKD if more signalHng will follow. 

c) After the status message has been successfully transported, a C_ACKD PDU. 

If a C_NACKD is received, the calling MS shall abandon the status message call and return to the idle state. 
If a C_WACKD is received the MS shall start/restart the TNP_Timer and wait for further signalling. 
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Any acknowledgement or valid C_AHOY PDU received shall restart the TNP_timer. 



6.6.6.1.2.4 



Timeout waiting for further signalling 



A MS waiting for further signalling shall abandon the status message service and return to the idle state if the 
TNP_Timer expires. 



6.6.6.1.2.5 



MS receiving a status message 



If a MS receives a C_AHOY message with the Target Address matching its individual address, it shall respond with an 
appropriate acknowledgement. The Service_Options information element contains the status message. 

6.6.7 Call Diversion 



6.6.7.1 



Call Diversion Service 



The call diversion service supports a self initiated diversion - that is a MS may request that all future services be 
redirected to an alternative destination. Requests are applicable to: 

a) Voice call service. 

b) Packet Data service. 

c) Short data message delivery service. 

d) Status message service. 

Applicable Services may be redirected to another MS, a talkgroup, or an extended address through a gateway. 

The "Set Diversion" call diversion service uses a multi-part call set-up and the diversion address is sent by the caller 
using the UDT mechanism. This is recognized by the DIVONOFF information element in the diversion service request 
set to "Set Call Diversion" (=12). 



TSCC 
Outbound 



MS(A) 
Inbound 



















UDT Uplink 
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Figure 6.45: Example of a Call Diversion Call 

MS (A) defines the number of appended UDTs needed to transport the diverted address to the TSCC. In this 
example, one appended UDT is required. 

"A" is the random access C_RAND PDU. The Service_Kind set to 'Call Diversion Service' and the 
Appended_Short_Data PDU to the number of UDT appended blocks to transport the diverted address. 

"B" is a C_AHOY PDU that requests MS(A) to transport the diversion address using the UDT mechanism. 

"C" is the inbound phase consisting of a Multi-block UDT header + appended data transporting the diverted 
address to the TSCC. 



e) "D" is the acknowledgement from the TSSC. 

If the Service_Options information element DIVONOFF in the call diversion Service request is set to "Clear Diversion" 
then a single part call set-up with the Target Address set to DIVERTI. 
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6.6.7.1.1 



TSCC Procedures for the Call Diversion Service 



A MS initiates a Set Call Diversion Service by random access addressed to the gateway identifier appropriate to the 
diverted destination - individual MS address, talkgroup, PTSN, PABX, IP. The set call diversion service uses the multi- 
part call set-up. When the TSCC responds to the random access request it shall start timer (TNP_Timer). This timer 
shall be refreshed if the TSCC sends further call progress PDUs to the calling party. 

A MS initiates a Clear Call Diversion Service by random access addressed to the gateway identifier DIVERTI. The 
clear call diversion service uses the single-part call set-up. When the TSCC responds to the random access request it 
shall start timer (TNP_Timer). This timer shall be refreshed if the TSCC sends further call progress PDUs to the calling 
party. 



6.6.7.1.1.1 



TSCC Response to a multi-part Set Call Diversion Service call setup 



To set call diversion service, the MS generates a random access diversion service request with the C_RAND 
information elements set as table 6.41 and the DIVONOFF information element set to Set Call Diversion (=12). 

The PDUs that shall represent a valid response to the set call diversion service multi-part random access request are: 

a) An acknowledgement PDU C_NACKD, C_WACKD(reason=Wait). 

b) A C_AHOY PDU for the calling MS to send the diverted address using the UDT mechanism. 

For b) The TSCC shall invoke the UDT procedure by sending a C_AHOY to the calling MS to send the diverted 
address information. For a call diversion to the PABX or PSTN the diverted address information shall be BCD digits. 
The Proxy Flag information element in the C-AHOY PDU shall be copied from the Proxy Flag information element 
received from the MS C_RAND PDU. If the TSCC does not successfully receive the UDT from the MS, the TSCC may 
repeat the C_AHOY, or transmit a C_NACKD to indicate failure of the call. 

The gateway information elements for C_AHOY PDUs to upload the diverted address is prescribed in table 6.40. 
Table 6.40: C AHOY information elements for the Set Call Diversion Service 



Action 


Gateway 
Address 


Remark 


Send the individual IVIS Address 


MSI 


The calling party shall send the MS Individual diversion address 


Send the Talkgroup Address 


GPI 


The calling party shall send the MS talkgroup diversion address 


Send PSTN digits 


PSTNI 


The calling party shall send BCD dialled digits 


Send PABX digits 


PABXI 


The calling party shall send BCD dialled digits 


Send IP address 


IPI 


The calling party shall send the IPV4 or IPV6 address 



6.6.7.1.1.2 



TSCC Response to a single-part Clear Call Diversion Service set-up 



For the clear call diversion service, the MS generates a random access diversion service request with the C_RAND 
information elements set as table 6.42 and the DIVONOFF information element set to Clear Call Diversion (=02). 

The PDUs that shall represent a valid response to the clear call diversion service multi-part random access request are: 

a) An acknowledgement PDU C_NACKD indicating that the service request has not succeeded. 

b) C_WACKD(reason=Wait) further signalling to follow. 

c) An acknowledgement C_ACKD indicating that the service request has succeeded. 

6.6.7.1 .2 MS Procedures for the Call Diversion Service 

A MS requests the call diversion service using a random access service request. 

If the MS wishes to divert its calls the DIVONOFF information element in the Service_Options is set to "Set Diversion 
(=12)". A multi-part service request is invoked. The information elements in the random access request are passed to the 

CC layer - set appropriately as prescribed in table 6.41. 

If the MS wishes to cancel a previously set diversion, the same random access request is. 
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Table 6.41 : C RAND information elements for a Call Diversion Service 



Information 
Element (I.E) 


I.E 
Length 


length 


Alias 


Value 


Remark 


Service_Options 


7 


1 


EMERG 


Not applicable - O2 


1 




02 


Privacy (see note) 


1 


DIVONOFF 


02 


Clear Call Diversion 


I2 


Set Call Diversion 


1 


DIV VD 


Active 1 2 
Inactive Oj 


Divert Voice Calls 


1 


DIV PD 


Divert Packet Data Calls 


1 


DIV SD 


Divert Short Data Calls 


1 


DIV S 


Divert Status Calls 


Proxy Flag 


1 




PROXY 


O2 


Number of Extended BCD digits for 
addressing through a gateway = 1 to 20 
or IPV4 


I2 


Number of Extended BCD digits for 
addressing through a gateway = 21 to 44 
or IPV6 


Appended_Supplem 
entary Data 


2 




SUPED_VAL 


OO2 


Not Defined for the call diversion Service 


Appended_Short_ 
Data 


2 




SDATA_VAL 


OO2 


Not Defined for the call diversion Service 


Service_Kind 


4 




DIV_SRV 


IOOO2 


Call Diversion Service 


Target_address or 
Gateway 


24 






value 


Gateway Identifier - MSI, GPI, PSTNI, 
PABXI, IPI 


Source address 


24 






Value 


Individual Address of the requesting MS 


NOTE: Privacy is not defined in the present document. 



If DIV0N0FF=l2, the alias DIV_VD, DIV_PD, DIV_SD and DIV_S that are set to Active (I2): define which services 
shall be diverted for this call diversion service request. 

If DIVONOFF=02, the aUas DIV_VD, DIV_PD, DIV_SD and DIV_S that are set to Active (I2): define which services 
shall have the call diversion cancelled. 

Table 6.42: Information element definitions for the Call Diversion Service 



Diversion Address 


Target Address or Gateway 


Proxy Flag 


Individual MS Address 


MSI 


O2 


Talkgroup Address 


GPI 


O2 


PSTN Address (1 to 20 dialled digits) 


PSTNI 


O2 


PSTN Address (21 to 44 dialled digits) 


PSTNI 


I2 


PABX Address(1 to 20 dialled digits) 


PABXI 


O2 


PABX Address (21 to 44 dialled digits) 


PABXI 


I2 


Ipv4 Address 


IPI 


O2 


Ipv6 Address 


IPI 


I2 



6.6.7.1.2.1 



MS Sends the Diversion Address 



After the MS has made a call diversion service request, the TSCC sends a C_AHOY PDU to which the MS shall 
respond with a UDT Header + Appended block(s) using the UDT mechanism. The UDT header shall contain the 
destination address type (MS, PSTN etc) and the appended block(s) shall contain the diversion address. 

The information elements for the UDT inbound Header are specified in table 6.43. 
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Table 6.43: Information element Definitions for the Call Diversion UDT Header 



Diversion Address 


UDT Inbound Channel Header Information Element 




UDT Format 


Appended Blocks 


Target 

Address or 

Gateway 


Source 

Address or 

Gateway 


Individual MS 


Address -0001 2 


OO2 


MSI 


IVIS Address 


Talkgroup 


Address -0001 2 


OO2 


GPI 


IVIS Address 


PSTN destination 


BCD- 001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PSTNI 


IVIS Address 


PABX destination 


BCD- 001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PABXI 


MS Address 


IP destination 


IP-OIIO2 


IPV4 - OO2 
IPV6-OI2 


IPI 


MS Address 


NOTE: Supplementary_Flag = O2, UDT_Response = O2, Service_Kind = IOOO2. 



6.6.7.2 



Diverting Calls 



An MS makes a service access request by random access. If the destination address selected is an individual MS address 
and the system determines that calls to this address are diverted, the TSCC shall acknowledge the random access 
request with a UDT header -\- appended with the diverted address. 
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Figure 6.46: TSCC provides diverted address to MS 

The UDT Header sets the following information elements: 

• DIV = I2. 

• Supplementary Flag = l2- 

• UDT Response - I2. 

• Target_address or Gateway - Address of the calling MS. 

Where the appended UDT block conveys an address the ADDRESS 1 information element shall convey the diverted 
address. 

Table 6.44 indicates the UDT Header information elements for the services and diversion addresses. 
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Table 6.44: Information elements for UDT Header to convey diverted address 



Service 
Request 


Divert to 


UDT Header information elements 






UDT 
Format 


Appended Blocks 


Service_Kind 


Source Address 


Private Voice 


MS 
address 


Address 
0001 2 


OO2 


OOOO2 


MSI 


Talkgroup 


Address 
0001 2 


OO2 


TGI 


PTSN 


BCD 
001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PSTNI 


PABX 


BCD 
001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PABXI 


Private 
Packet Data 


MS 
address 


Address 
0001 2 


OO2 


001 O2 


MSI 


Talkgroup 


Address 
0001 2 


OO2 


TGI 


PSTN 


BCD 
001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PSTNI 


PABX 


BCD 
001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PABXI 


IP 


IP 
OIIO2 


IPV4 - OO2 
IPV6-OI2 


IPI 


Short Data 


MS 
address 


Address 
0001 2 


OO2 


OIOO2 


MSI 


Talkgroup 


Address 
0001 2 


OO2 


TGI 


PTSN 


BCD 
001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PSTNI 


PABX 


BCD 
001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PABXI 


IP 


IP 
OIIO2 


IPV4-OO2 
IPV6-OI2 


IPI 


Status 


MS 
address 


Address 
0001 2 


OO2 


OIII2 


MSI 


PTSN 


BCD 
001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PSTNI 


PABX 


BCD 
001 O2 


1 to 20 digits - OO2 
21 to 44 digits -01 2 


PABXI 


IP 


IP 
OIIO2 


IPV4 - OO2 
IPV6-OI2 


IPI 



6.7 System Management Procedures 
6.7.1 Network System Announcements 

Announcement PDUs are transmitted by a TSCC and contain information about system parameters for either this TS or 
another TS. Announcement PDUs may be transmitted frequently and therefore contain the System Identity Code for 
TSCC identification. 

Announcement Type (BCASTTYP) specifies which system parameters are being broadcast: 

a) AnnounceAVithdraw TSCC. 

b) Specify Call Timer Parameters. 
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c) Vote Now Advice. 

d) Announce Local Time. 

e) Mass registration. 

f) Announce a logical/physical frequency plan relationship. 

g) Adjacent site information. 

6.7.1 .1 Announce/Withdraw TSCC 

This announcement adds and/or withdraws a TSCC radio channel that is active in a wide area system. The 
announcement PDU carries up to two Logical Physical Channel Number Elements. If only one Logical Channel 
Number is announced, the remaining element shall be set to CHNULL. MSs shall add/withdraw the logical channel(s) 
to/from their Short Hunt list of physical channels to hunt (see annex D). 

6.7.1 .2 Specify Call Timer parameters 

This PDU specifies the call timer parameters for: 

a) Calls between MS and MS or MS and a talkgroup. 

b) Calls between a Line Connected Service and an MS or Talkgroup. 

c) Calls that use the Packet Data Service. 

d) Emergency Calls. 

6.7.1 .3 Vote now advice 

The Network System Announcements (Vote Now Advice) PDU gives an opportunity to idle MSs to assess the signal 
quality of another TSCC specified by the announcement(see clause 7.2.20.3). The PDU provides a sub-set of the system 
identity code (C_SYSCode), and the logical channel number (CH_VOTE) of the TSCC the MS is being invited to 
assess for improved signal quality. 

While MSs are assessing the signal quality of an adjacent TSCC, they are not able to receive call set-up PDUs. The 
TSCC shall therefore not use the next VOTE_BLK TDMA frames to signal to MSs that are likely to be assessing the 
signal strength of the adjacent site. Only the following PDUs may be transmitted on the TSCC in the VOTE_BLK slots 
following transmission of a Vote Now Advice announcement: 

a) An Aloha PDU with MS Address = NULL and Mask=24. 

b) A C_WACKD. 

6.7.1 .4 Announce Local Time 

This PDU transmits the local date and time to MSs. The PDU permits the date to be omitted from the announcement. 
UTC_OFFSET enables the MS to calculate UTC time. 

6.7.1 .5 Mass Registration 

This PDU invites all MS or a sub-set of MS to register over a short or extended time period. The description and 
procedures are specified in the registration clauses 6.4.5. 

6.7.1 .6 Announce a logical physical channel relationship 

This PDU announces a logical to physical channel relationship. The PDU defines the physical transmitter and receiver 
frequencies to be assigned to a logical channel. 
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7 PDU description 

This clause describes the PDUs which apply to the DMR layer 3, the tier III trunking services and facilities protocol. 

The following clauses contain descriptions of the PDUs and the information elements contained within them. The 
structure of the PDU definition represented by the tables is as follows: 

• the information element column gives the name of the contained element(s); 

• the element length column defines the length of the element in bits; 

• the Alias used in the description of the procedures; 

• the remarks column contains other information on the information element. 
The elements shall be transmitted in the order specified by TS 102 361-1 [5]. 



7.1 Layer 3 PDUs 



Due to the nature of DMR, with close interaction between layers 2 and 3, and with a high degree of information about 
the state of the channel being needed, the layer 3 PDUs detailed in the following clauses may include two element 
types: 

• Message dependent elements: 

These elements are visible to layer 2 and may be used by any MS (that is able to decode them), 
irrespective of addressing. These elements depend on the message type element. Some are generated by 
layer 2 when it constructs the complete message whereas others are generated by layer 3. 

• Facility elements: 

These are "true" layer 3 elements. They are only processed by the MSs to which they are addressed. 
Where both types exist in the PDU they are shown separately. 

7.1 .1 Control Signalling Block (CSBK/MBC/UDT) PDUs 

CSBK/MBC and UDT PDUs form a core part of the tier III protocol. The control signalling PDUs are classified into 
their core functionality. 

The Call Control Layer 3 requires three Data Type bursts (see TS 102 361-1 [5], clause 6.2). These are listed in: 

• table 7. 1 for TSCC outbound PDUs; 

• table 7.2 for TSCC inbound PDUs; 
table 7.3 for Payload channel outbound PDUs; and 
table 7.4 for Payload inbound PDUs. 



• 



• 



ETSI 



124 



ETSI TS 102 361-4 V1.2.1 (2006-09) 



Table 7.1 : TSCC Outbound channel PDU Structure 



Class 


Alias 


Function 


Opcode 


Data Type 


Value 


Broadcast 


PV_GRANT 


Private Voice Channel Grant 
(logical) 


1 1 OOOO2 


CSBK 


OOII2 


Private Voice Channel Grant 
(absolute) 


MBC Header 


OIOO2 


Broadcast 


TV_GRANT 


Talkgroup Voice Channel 
Grant (logical) 


11 0001 2 


CSBK 


OOII2 


Talkgroup Voice Channel 
Grant (absolute) 


MBC Header 


OIOO2 


Broadcast 


BTV_GRANT 


Broadcast Talkgroup Voice 
Channel Grant (logical) 


11 001 O2 


CSBK 


OOII2 


Broadcast Talkgroup Voice 
Channel Grant (absolute) 


MBC Header 


OIOO2 


Broadcast 


PD_GRANT 


Private Data Channel Grant 
(logical) 


11 001 12 


CSBK 


OOII2 


Private Data Channel Grant 
(absolute) 


MBC Header 


OIOO2 


Broadcast 


TD_GRANT 


Talkgroup Data Channel 
Grant (logical) 


11 01002 


CSBK 


OOII2 


Talkgroup Data Channel 
Grant (absolute) 


MBC Header 


OIOO2 


Broadcast 


CG_AP 


Channel Grant Appended 
MBC 


Value 

from 

header 


MBC 
Continuation 


OIOI2 


Broadcast 


C_MOVE 


Move TSCC (logical) 


11 IOOO2 


CSBK 


OOII2 


Move TSCC (absolute) 


MBC Header 


OIOO2 


Broadcast 


MV_AP 


Move Appended MBC 


11 IOOO2 


MBC 
Continuation 


OIOI2 


Broadcast 


C_ALOHA 


Aloha 


01 IOOI2 


CSBK 


OOII2 


Broadcast 
(C_BCAST) 


Ann WD 
TSCC 


Announce/Withdraw TSCC 
(logical) 


IOIOOO2 


CSBK 


OOII2 


Ann WD 
TSCC 


Announce/Withdraw TSCC 
(absolute) 


MBC Header 


OIOO2 


CallTimer 
Parms 


Specify Call Timer 
Parameters 


CSBK 


OOII2 


Vote_Now 


Vote Now Advice 


CSBK 


OOII2 


Local_Time 


Broadcast Local Time 


CSBK 


OOII2 


IVIassReg 


Broadcast Mass Registration 


CSBK 


OOII2 


Chan_Freq 


Announce a logical channel / 
frequency relationship 


CSBK 


OOII2 


Broadcast 


BC_AP 


Broadcast Appended MBC 


IOIOOO2 


MBC 
Continuation 


OIOI2 


Ahoy 
(AHOY) 


AHOY 


Stun/Unstun 
Poll MS 
MS Check 


01 IIOO2 


CSBK 


OOII2 


Acknowledg 
ements 


C ACKD 
C NACKD 
C QACKD 
C WACKD 


Positive Acknowledgement 
Negative Acknowledgement 
The call is queued 
Wait - further PDUs follow 


IOOOOO2 


CSBK 


OOII2 


Unified 

Data 

Transport 


C_UDTHD 


Unified Data Transport 
Header 


N/A 


Data Header 
(UDT) 


OIIO2 


Unified 

Data 

Transport 


UDT 


Unified Data Transport 
Appended Data 


N/A 


Unconfirmed 

Data 
Continuation 


OIII2 
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Table 7.2: TSCC Inbound Channel PDU Structure 



Class 


Alias 


Function 


Opcode 


Data Type 


Value 


Random 
Access 


C_RAND 


Random Access Requests 


01 111I2 


CSBK 


OOII2 


Ackvitation 


C_ACKVIT 


Ackvitation 


01 IIIO2 


CSBK 


OOII2 


Acknowledg 
ement 


C ACKU 
C NACKU 


Acknowledgement 


10 0001 2 


CSBK 


OOII2 


Unified 

Data 

Transport 


C_UDTHD 


Unified Data Transport 
Header 


N/A 


Data Header 
(UDT) 


OIIO2 


Unified 

Data 

Transport 


UDT 


Unified Data Transport 
Appended Data 


N/A 


Unconfirmed 

Data 
Continuation 


OIII2 



Table 7.3: Payload Outbound channel PDU Structure 



Class 


Alias 


Function 


Opcode 


Data Type 


Value 


Broadcast 


P_GRANT 


Channel Grant (logical) 


Value 
from 
Chan 
Grant 


CSBK 


OOII2 


Private Voice Channel Grant 
(absolute) 


MBC Header 


OIOO2 


Broadcast 
(Clear) 


P_CLEAR 


Clear the call from the 
payload channel. MS return 
to the TSCC 


IOIIIO2 


CSBK 


OOII2 


Broadcast 
(Protect) 


P_PROTECT 


Broadcast Talkgroup Voice 
Channel Grant (logical) 


IOIIII2 


CSBK 


OOII2 


Ahoy 


P_AHOY 


MS Check 


01 IIOO2 


CSBK 


OOII2 


Acknowledg 
ements 


P ACKD 
P NACKD 


Positive Acknowledgement 
Negative Acknowledgement 


IOOOOO2 


CSBK 


OOII2 



Table 7.4: Payload Inbound Channel PDU Structure 



Class 


Alias 


Function 


Opcode 


Data Type 


Value 


Random 
Access 


P_RAND 


Random Access Include 
Request 


01 IIII2 


CSBK 


OOII2 


Acknowledg 
ement 


P_ACKU 


Acknowledgement 


10 0001 2 


CSBK 


OOII2 


Maintenance 


P_MAINT 


Call Maintenance 


1010102 


CSBK 


OOII2 
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Figure 7.1 illustrates the hierarchy of the TSCC outbound channel PDU structure. 
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Acknowledgements 



Unified Data 
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Download 




Figure 7.1 : Hierarchy for tlie TSCC outbound channel PDUs 

The top level of the structure describes a basic behaviour shown in table 7.5. 

Table 7.5: Top Level Structure for TSCC Outbound channel CSBKs / MBCs /UDTs 



Broadcasts 


PDUs sent by a TSCC to manage the channel access, transfer MS or talkgroups 
to payload channels and announce information about the TS 


Ahoys 


To demand a response from MS and also to acknowledge random access 
channel access 


Acknowledgments 


To provide responses to Ahoys and UDT 


UDT 


To transport information between TSCC and MS 



A similar structure exists for the inbound channel illustrated in figure 7.2. 
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SLOT 
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Figure 7.2: Hierarchy for the MS inbound channel PDUs to a TSCC 

The basic PDU behaviour for the inbound channel is shown in table 7.6. 

Table 7.6: Top level structure for MS on the TSCC inbound 



Random Access 


Used for channel access and request tier III services 


Acknowledgments 


To provide responses to Ahoys and UDT 


UDT 


To transport information between MS and TSCC 



A payload channel outbound channel is illustrated in figure 7.3. 
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Figure 7.3: Hierarchy for Outbound channel CSBKs/MBCs on a payload channel 

The top level of the structure describes a basic behaviour shown in table 7.7. 

Table 7.7: Top level structure for MS inbound channel CSBKs on a control channel 



Broadcasts 


PDUs sent by TS to manage the payload channel - swap MS to a new channel, 
clear the participants from the channel and protect the channel during breaks in 
MS transmission items 


Ahoys 


For polling MS - demands a response 


Acknowledgments 


To provide responses to Ahoys and UDT 
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The payload inbound channel. 
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Figure 7.4: Hierarchy for the MS inbound channel PDUs to a payload channel 

The basic PDU behaviour for the inbound channel is shown in table 7.8. 

Table 7.8: Top level structure for MS on the payload channel inbound channel 



Random Access 


Used to request an include call service 


Acknowledgments 


To provide responses to Ahoys and UDT 


Maintenance 


To provide call maintenance PDUs 



7.1.1.1 



TSCC Outbound channel CSBK/MBC/UDT 



7.1.1.1.1 



7.1.1.1.1.1 



Channel Grant CSBK/MBC PDU 



Private Voice Channel Grant (PV_GRANT) CSBK/MBC PDU 



Octet and 1 of the Private Voice Channel Grant CSBK PDU conforms to the LC format structure as defined in 
figure 7.1 in TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the Private 
Voice Channel Grant specific information shown in table 7.9. The Private Voice Channel Grant is transmitted by the TS 
and does not solicit a response. The Private Voice Channel Grant PDU is transmitted on the TSCC or a payload channel 
either as a single block CSBK or a Multi Block Control (MBC). For the Physical Channel Number Information 
Element: 

a) If the value = 0000 0000 OOOO2 the Physical Channel number is invalid. 

b) If the value = 0000 0000 0001 2 to 1 1 1 1 1 1 1 1 1 1 IO2, the Physical Channel number represent a logical channel 
number for the physical transmitter and receiver frequency. The Private Voice Channel Grant PDU is 
transmitted on the TSCC as a single block CSBK. 

c) If the value = 1111 1111 1111 2, the Physical Channel number defines a multi -block MBC where the absolute 
transmitter and receiver frequency is defined in a second block concatenated to this block (defined in 
clause 7.1.1.1.2). 
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Figure 7.5 



Table 7.9: Private Voice Channel Grant PDU content 



Information element 


Length 


Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to 1 2 for a single block CSBK or O2 if this is a 
MBC header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 1 1 OOOO2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Logical Physical Channel 
Number 


12 


Payload Channel for the Call or an indicator that the absolute Tx & 
Rx frequency is specified in an appended CSBK block 


Logical Channel Number 


1 


O2 - TDMA channel 1 
I2-TDMA channel 2 


OVCM 


1 


O2 - not OVCM call 
I2- OVCM Call 


Emergency 


1 


O2 - not an emergency call 
^2- emergency call 


Offset 


1 


O2 - Payload Channel uses aligned timing 
I2 - Payload Channel uses offset timing 


Target Address 


24 


Called party Individual MS Address or Gateway 


Source Address 


24 


Calling Party or Gateway 



7.1.1.1.1.2 



Talkgroup Voice Channel Grant (TV_GRANT) CSBK/MBO PDU 



Octet and 1 of the Talkgroup Voice Channel Grant CSBK PDU conforms to the LC format structure as defined in 
figure 7.1 in TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the 
Talkgroup Voice Channel Grant specific information shown in table 7.10. The Talkgroup Voice Channel Grant is 
transmitted by the TS. The Talkgroup Voice Channel Grant is transmitted by the TS and does not solicit a response. The 
Talkgroup Voice Channel Grant PDU is transmitted on the TSCC or a payload channel either as a single block CSBK 
or a Multi Block Control (MBC). For the Physical Channel Number Information Element: 

a) If the value = 0000 0000 OOOO2 the Physical Channel number is invaUd. 
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b) If the value = 0000 0000 0001 2 to 1 1 1 1 1 1 1 1 1 1 IO2, the Physical Channel number represent a logical channel 

number for the physical transmitter and receiver frequency. The Talkgroup Voice Channel Grant PDU is 
transmitted on the TSCC as a single block CSBK. 

c) If the value = 1 1 1 1 1 1 1 1 1 1 1 12, the Physical Channel number defines a Multi Block Control (MBC) where the 

absolute transmitter and receiver frequency is defined in a second block concatenated to this block (defined in 
clause 7.1.1.1.2). 
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Figure 7.6 
Table 7.10: Talkgroup Voice Channel Grant PDU content 



Information element 


Length 


Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to 1 2 for a single block CSBK or O2 if this is a 
MBC header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 11 0001 2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Logical Physical Channel 
Number 


12 


Payload Channel for the Call or an indicator that the absolute Tx & 
Rx frequency is specified in an appended CSBK block 


Logical Channel Number 


1 


O2 - TDMA channel 1 
I2-TDMA channel 2 


OVCM 


1 


O2 - not OVCM call 
I2- OVCM Call 


Emergency 


1 


O2 - not an emergency call 
I2- emergency call 


Offset 


1 


O2 - Payload Channel uses aligned timing 
I2 - Payload Channel uses offset timing 


Target Address 


24 


MS Talkgroup Address 


Source Address 


24 


Calling Party or Gateway 
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If the Target Address is the All Unit Address (see TS 102 361-1 [5], annex A) then a MS shall interpret this PDU as a 
broadcast. 



7.1.1.1.1.3 



Broadcast Talkgroup Voice Channel Grant (BTV_GRANT) CSBK/MBO PDU 



Octet and 1 of the Broadcast Talkgroup Voice Channel Grant CSBK PDU conforms to the LC format structure as 
defined in figure 7.1 in TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the 
Broadcast Talkgroup Voice Channel Grant specific information shown in table 7.11. The Broadcast Talkgroup Voice 
Channel Grant is transmitted by the TS and does not solicit a response. The Broadcast Talkgroup Voice Channel Grant 
PDU is transmitted on the TSCC or a payload channel either as a single block CSBK or a Multi Block Control (MBC). 
For the Physical Channel Number Information Element: 

a) If the value = 0000 0000 OOOO2 the Physical Channel number is invahd. 

b) If the value = 0000 0000 000 1 2 to 1 1 1 1 1 1 1 1 1 1 IO2, the Physical Channel number represent a logical channel 
number for the physical transmitter and receiver frequency. The Broadcast Talkgroup Voice Channel Grant is 
transmitted on the TSCC as a single block CSBK. 

c) If the value = 1 1 1 1 1 1 1 1 1 1 1 12, the Physical Channel number defines a Multi-Block Control (MBC) where the 

absolute transmitter and receiver frequency is defined in a second block concatenated to this block (defined in 
clause 7.1.1.1.2). 
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Figure 7.7 
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Table 7.11 : Broadcast Talkgroup Voice Channel Grant PDU content 



Information element 


Length 


Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to 1 2 for a single block CSBK or O2 if this is a 
MBC header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to IIOOIO2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Logical Physical Channel 
Number 


12 


Payload Channel for the Call or an indicator that the absolute Tx & 
Rx frequency is specified in an appended CSBK block 


Logical Channel Number 


1 


O2 - TDMA channel 1 
I2-TDMA channel 2 


OVCM 


1 


O2 - not OVCM call 
I2- OVCM Call 


Emergency_Flag 


1 


l2-if an emergency call 


Offset 


1 


O2 - Payload Channel uses aligned timing 
I2 - Payload Channel uses offset timing 


Destination Address 


24 


MS Talkgroup Address 


Source address 


24 


Calling Party or Gateway 



7.1.1.1.1.4 



Private Data Channel Grant (PD_GRANT) CSBK/MBO PDU 



Octet and 1 of the Private Data Channel Grant CSBK PDU conforms to the LC format structure as defined in 
figure 7.1 in TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the Private 
Channel Grant specific information shown in table 7.12. The Private Data Channel Grant is transmitted by the TS and 
does not solicit a response. The Private Data Channel Grant PDU is transmitted on the TSCC or a payload channel 
either as a single block CSBK or a Multi Block Control (MBC). For the Physical Channel Number Information 
Element: 

a) If the value = 0000 0000 OOOO2 the Physical Channel number is invahd. 

b) If the value = 0000 0000 0001 2 to 1 1 1 1 1 1 1 1 1 1 IO2, the Physical Channel number represent a logical channel 
number for the physical transmitter and receiver frequency. The Private Data Channel Grant PDU is 
transmitted on the TSCC as a single block CSBK. 

c) If the value = 1 1 1 1 1 1 1 1 1 1 1 12, the Physical Channel number defines a Multi Block Control (MBC) where the 

absolute transmitter and receiver frequency is defined in a second block concatenated to this block (defined in 
clause 7.1.1.1.2). 
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Figure 7.8 



Table 7.12: Private Data Channel Grant PDU content 



Information element Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to 1 2 for a single block CSBK or 0^ if this is a 
MBC header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 11 0011 2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Logical Physical Channel 
Number 


12 


Payload Channel for the Call or an indicator that the absolute Tx & 
Rx frequency is specified in an appended CSBK block 


Logical Channel Number 


1 


O2 - TDMA channel 1 
I2-TDMA channel 2 


Packet Mode 


1 


O2 - Payload Channel uses 2:1 mode 
I2 - Payload Channel uses 1 :1 mode 


Emergency 


1 


O2 - not an emergency call 
I2- emergency call 


Offset 


1 


O2 - Payload Channel uses aligned timing 
I2 - Payload Channel uses offset timing 


Destination Address 


24 


Called party Individual MS Address or Gateway 


Source address 


24 


Calling Party or Gateway 



7.1.1.1.1.5 



Talkgroup Data Channel Grant (TD_GRANT) CSBK/MBC PDU 



Octet and 1 of the Talkgroup Data Channel Grant CSBK PDU conforms to the LC format structure as defined in 
figure 7.1 in TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the 
Talkgroup Data Channel Grant specific information shown in table 7.13. The Talkgroup Data Channel Grant is 
transmitted by the TS and does not solicit a response. The Talkgroup Data Channel Grant PDU is transmitted on the 
TSCC or a payload channel either as a single block CSBK or a Multi Block Control (MBC). For the Physical Channel 
Number Information Element: 

a) If the value = 0000 0000 OOOO2 the Physical Channel number is invahd. 
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b) 



c) 



If the value = 0000 0000 0001 2 to 1 1 1 1 1 1 1 1 1 1 IO2, the Physical Channel number represent a logical channel 

number for the physical transmitter and receiver frequency. The Talkgroup Data Channel Grant PDU is 
transmitted on the TSCC as a single block CSBK. 

If the value = 1 1 1 1 1 1 1 1 1 1 1 12, the Physical Channel number defines a Multi Block Control (MBC) where the 

absolute transmitter and receiver frequency is defined in a second block concatenated to this block (defined in 
clause 7.1.1.1.2). 
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Figure 7.9 
Table 7.13: Talkgroup Data Channel Grant PDU content 



Information element 


Length 


Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to 1 2 for a single block CSBK or O2 if this is a 
MBC header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 11 OIOO2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Logical Physical Channel 
Number 


12 


Payload Channel for the Call or an indicator that the absolute Tx & 
Rx frequency is specified in an appended CSBK block 


Logical Channel Number 


1 


O2 - TDMA channel 1 
I2-TDMA channel 2 


Packet Mode 


1 


O2 - Payload Channel uses 2:1 mode 
I2 - Payload Channel uses 1 :1 mode 


Emergency 


1 


O2 - not an emergency call I2 - emergency call 


Offset 


1 


O2 - Payload Channel uses aligned timing 
I2 - Payload Channel uses offset timing 


Destination Address 


24 


MS Talkgroup Address 


Source address 


24 


Calling Party or Gateway 



7.1.1.1.2 



Channel Grant Absolute Parameters (CG_AP) appended MBC PDU 



The second (continuation) block of the multi-block Channel Grant MBC conforms to the format specified in table 7.14. 
The CdefParms PDU is specified in clause 7.2.20.8 and the physical characteristics described in annex C. 
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Table 7.14: C_DEF appended Channel Grant MBC PDU content 



Information element Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to ^2 because this PDU is appended to either a 
an applicable Channel Grant MBC Header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to the CSBKO of the first block of the multi-block 
CSBK 


Reserved 


4 


OOOO2 


Colour Code 


4 


Colour Code used for the destination physical channel 


Cdeftype 


4 


Meaning of CdefParms (see clause 7.2.20.8) 


Reserved 


2 


OO2 


CdefParms 


58 


information elements describing the logical / physical channel 
frequency relationship 



7.1.1.1.3 



Move TSCC (C_MOVE) CSBK/MBC PDU 



Octet and 1 of the Move TSCC CSBK PDU conforms to the LC format structure as defined in figure 7.1 in 
TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the Move TSCC specific 
information shown in table 7.15. The Move PDU is transmitted on the TSCC either as a single block CSBK or a Multi 
Block Control (MBC). For the Physical Channel Number Information Element: 

a) If the value = 0000 0000 OOOO2 the Physical Channel number is invahd. 

b) If the value = 0000 0000 0001 2 to 1 1 1 1 1111 1 1 IO2, the Physical Channel number represent a logical channel 

number for the physical transmitter and receiver frequency. The Move PDU is transmitted on the TSCC as a 
single block CSBK. 

c) If the value = 1 1 1 1 1 1 1 1 1 1 1 12, the Physical Channel number defines a Multi Block Control (MBC) where the 
absolute transmitter and receiver frequency is defined in a second block concatenated to this block (see 
clause 7.1.1.1.3.1). 
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Table 7.15: Move TSCC PDU content 



Information element Length 


Remark 


Message dependent elements | 


Last First block (LB) 


1 


This bit shall be set to 1 2 for a single block CSBK or O2 if this is a MBC 
header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 11 IOOO2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Reserved 


9 


0000 OOOO2 


Mask 


5 




Reserved 


5 




Reg 


1 


This bit is set if the TSCC demands MS register before becoming active 


Backoff 


4 


Backoff Number 


Reserved 


4 




Physical Channel Number 


12 


Payload Channel for the Call or an indicator that the absolute Tx & Rx 
frequency is specified in an appended CSBK block 


MS address 


24 


MS Individual Address 



7.1.1.1.3.1 



Move Absolute Parameters appended (MV_AP) MBC PDU 



The second block of the Multi Block Move MBC conforms to the format specified in table 7.16. The CdefParms PDU 
is specified in clause 7.2.20.8 and the physical characteristics described in annex C. 

Table 7.16: C_DEF appended Move MBC PDU content 



Information element Length 


Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to I2 because this PDU is appended to an 
applicable Move MBC Header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to the CSBKO of the first block of the multi-block 
CSBK 


Reserved 


4 


OOOO2 


Colour Code 


4 


Colour Code used for the destination physical channel 


Cdeftype 


4 


Meaning of CdefParms (see clause 7.2.20.8) 


Reserved 


2 


OO2 


CdefParms 


58 


information elements describing the logical / physical channel 
frequency relationship 



7.1.1.1.4 



Aloha (C_ALOHA) CSBK PDU 



Octet and 1 of the C_ALOHA CSBK PDU conforms to the LC format structure as defined in figure 7.1 in 

TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the C_ALOHA PDU 

specific information. The C_ALOHA PDU is shown in table 7.17. C_ALOHA PDUs are transmitted by a TSCC. 
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Table 7.17: C ALOHA PDU content 



Information element 


Length 


Remark 




Message dependent elements 


Last block (LB) 


1 


This bit shall be set to ^2 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 01 1001 2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Reserved 


7 




Active_Connection 


1 


O2 - The TS does not have a connection with the network 
I2 - The TS has a connection with the network 


Mask 


5 




Service Function 


2 




NRand Wait 


4 




Reg 


1 


This bit is set if the TSCC demands MS register before becoming 


active 


Backoff 


4 


Backoff Number 


System Identity Code 


16 




MS Address 


24 


MS Individual Address 



7.1.1.1.5 



Announcements (C_BCAST) CSBK/MBC PDU 



Octet and 1 of the C_BCAST PDU conforms to the LC format structure as defined in figure 7.1 in TS 102 361-1 [5] 
of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the C_BCAST PDU specific information. 
The C_BCAST PDU is transmitted on the TSCC either as a single block CSBK or a Multi Block Control (MBC). 

The C BCAST PDU is shown in table 7.18. 
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Table 7.18: C BCAST PDU content 



Information element Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to 1 2 for a single block CSBK or O2 if this is a MBC header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shallbesetto10 10002 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Announcement type 


5 


Defines which system parameters are being broadcast 


Broadcast Parms 1 


14 




Reg 


1 


This bit is set if the TSCC demands MS register before becoming active 


Backoff 


4 


Backoff Number 


System Identity Code 


16 




Broadcast Parms 2 


24 





The Announcement type PDU determines the category of Announcements: 

a) AnnounceAVithdraw TSCC. 

b) Specify call Timers. 

c) Vote now advice. 

d) Announce local time. 

e) Broadcast Mass Registration. 

f) Announce a logical physical channel relationship. 

g) Announce adjacent site information. 
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7.1.1.1.5.1 



Broadcast Absolute Parameters (BC_AP) appended MBC PDU 



The second block of the multi-block Broadcast Absolute Parameters MBC (announce logical/absolute frequency 
relationship) conforms to the format specified in table 7.19. The CdefParms PDU is specified in clause 7.2.20.8 and the 
physical characteristics described in annex C. 

Table 7.19: BC_AP appended Broadcast MBC PDU content 



Information element 


Length 


Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to O2 because this PDU is appended to an 
applicable Announcement MBC Header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to the CSBKO of the first block of the multi-block CSBK 


Reserved 


8 




Cdeftype 


4 




Reserved 


2 




CdefParms 


58 


Information elements describing the logical / physical channel frequency 
relationship 



7.1.1.1.6 



Ahoy (AHOY) CSBK PDU 



Octet and 1 of the AHOY CSBK PDU conforms to the LC format structure as defined in figure 7.1 in 

TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the C_AHOY specific 

information. The generic AHOY PDU is shown in table 7.20. AHOY PDUs are transmitted by the TS. 

The AHOY PDU is transmitted by the TS as a single block CSBK. 
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Table 7.20: AHOY PDU content 



Information element Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to ^2 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 01 IIOO2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Service Options Mirror 


7 




Service Kind Flag 


1 


Meaning dependent on Service Kind 


Reserved 


2 


OO2 


Appended_Blocks 


2 


For a demand to the MS to send a multi-block CSBK, the number 
of appended data blocks 


Service Kind 


4 


Service for which this C AHOY is supporting 


Target address 


24 


Address of Called MS 


Source Address or Gateway 


24 


Address of calling party MS or gateway, or Authentication 
challenge value 



7.1.1.1.7 



Acknowledgement C_ACKD) TSCC Response CSBK PDU 



Octet and 1 of the Acknowledge Response (C_ACKD) CSBK PDU conforms to the LC format structure as defined in 
figure 7.1 in TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the 
Acknowledge Response specific information. The generic Acknowledge Response PDU is shown in table 7.21. 
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NOTE: Acknowledgement Responses are transmitted by both TS and MS. 
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Table 7.21 : TS Acknowledgement Response PDU content 



Information element 


Length 


Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to ^2 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to10 00002 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 








Response Info 


7 


Supplementary response information 


Reason Code 


8 




Source Type 


1 


O2 - the acknowledgement is sourced by the TS 








Target address 


24 


Address of Called MS 


Additional Information 
(Source Address) 


24 


Address of calling party MS or gateway 



Acknowledge Response PDUs are arranged into classes: 
C_ACKD - Positive Acknowledgement. 
C_NACKD - Negative Acknowledgement. 
C_QACKD - Queued. 
C_WACKD - Intermediate Acknowledgement. 



7.1.1.1.8 



Unified Data Transport Download Header (C_UDTHD) UDT PDU 



This PDU is a multi -block UDT conforming to the format specified in table 7.22. The number of UDT Appended data 
blocks is indicated by the Appended Blocks (UAB) information element. 

The UDT Appended Data Format is prescribed in annex B. 
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NOTE: UDT Headers are transmitted by both TS and MS. 

Table 7.22: Unified Data Transport Download Header PDU content 



Information element Length Remark 


Feature elements 


Elements defined in TS 102 361-1 [5] 


G/l (IG) 


1 


O2 = Destination is an individual MS address 


I2 = Destination is a Talkgroup address. Response not expected 


A 


1 


O2 = Response not expected if Destination is an individual MS 
address 


I2 = Response demanded if Destination is an individual MS 
address 


Reserved 


2 




Format 


4 


IIIO2 


SAP 


4 


Service Access Point - OOOO2 for UDT 


UDT Format 


4 


Format of the data following the UDT Header 


Target_address or Gateway 


24 




Source address or Gateway 


24 




Pad Nibble 


5 




Reserved 


1 


02 


Appended_Blocks(UAB) 


2 


Number of Blocks appended to this UDT Header 
OO2 = 1 Appended Data UDT block 
OI2 = 2 Appended Data UDT blocks 
IO2 = 3 Appended Data UDT blocks 
1 12 = 4 Appended Data UDT blocks 


Supplementary_Flag(SF) 


1 


O2 = This UDT Header is carrying the data for a user initiated 

service (Short Data, Data Polling) 

I2 = This UDT Header is carrying supplementary data, supporting 

another tier III service. 


Protect Flag (PF) 


1 


Reserved for Future Use 


Opcode (UDTO) 


6 


Shall be set to 01 IOIO2 


NOTE: Shaded rows are information elements that are defined in TS 102 361-1 [5]. 



7.1.1.2 



TSCC Inbound channel CSBKs/UDTs transmitted by MS 



7.1.1.2.1 



Random Access Request (C_RAND) PDU 



Octet and 1 of the Random Access CSBK (C_RAND_CSBK) PDU conform to the LC format structure as defined in 
figure 7.1 in TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the Random 
Access Request specific information specified in table 7.23. Random Access Requests are sent by MS. 
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Table 7.23: Random Access Request PDU content 



Information element Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to ^2 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 01 IIII2 


Manufacturers Feature ID 


8 


Shall be set to 0000 OOOO2 


Service Options 


7 




Proxy Flag 


1 


O2 - Number of Extended BCD digits for addressing through a 

gateway = 1 to 20 

^2- Number of Extended BCD digits for addressing through a 

gateway = 21 to 44 


Appended_Supplementary_Data 


2 


Number of appended CSBKs required to transport supplementary 
data 


Appended Short Data 


2 


Number of appended CSBKs required to transport short data 


Service Kind 


4 


Service requested 


Target_address or Gateway 


24 




Source address 


24 


Address of the requesting MS 



7.1.1.2.2 



C_Ackvitation (C_ACKVIT) CSBK PDU 



Octet and 1 of the C_ACKVIT CSBK PDU conforms to the LC format structure as defined in figure 7.1 in 

TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the C_Ackvitation specific 

information. The generic C_Ackvitation PDU is shown in table 7.24. C_Ackvitation PDUs are transmitted by MS. 

The C_Ackvitation PDU is transmitted by the MS as a single block CSBK. 
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Table 7.24: C Ackvitation PDU content 



Information element Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to 1 2 for a single block CSBK or O2 for a all 
but the last block of a multi-block CSBK 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 01 111 O2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Service Options Mirror 


7 




Service Kind Flag 


1 


Meaning dependent on Service Kind 


Reserved 


2 


OO2 


Appended_Blocks (UAB) 


2 


For a demand to the TS to send a multi-block CSBK, the number 
of appended data blocks 


Service Kind 


4 


Service for which this C_AHOY is supporting 


Target address 


24 


Address of Called MS 


Source Address or 
Gateway or Authentication 


24 


Address of calling party MS or gateway, or Authentication 
challenge value 



7.1.1.2.3 



C_Acknowledge (C_ACKU) MS Response CSBK PDU 



Octet and 1 of the Acknowledge Response CSBK PDU conforms to the LC format structure as defined in figure 7.1 in 
TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the Acknowledge 
Response specific information. The generic Acknowledge Response PDU is shown in table 7.25. 
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Figure 7.18 

NOTE: Acknowledgement Responses are transmitted by both TS and MS. 
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Table 7.25: MS Acknowledge Response PDU content 



Information element Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to ^2 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 10 0001 2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Response Info 


7 


Supplementary response information 


Reason Code 


8 




Source Type 


1 


I2 - acknowledgement sourced by the MS 


Target address or 
Authentication 


24 


The Source Address from the TS PDU for which this 
acknowledgement is being transmitted or authentication challenge 
response if this acknowledgement is being transmitted as part of 
authentication challenge 


Additional Information 
(Source Address) 


24 


MS individual address that is transmitting the acknowledgement 



Acknowledge Response PDUs are arranged into classes: 
C_ACKU - Positive Acknowledgement. 
C_NACKU - Negative Acknowledgement. 



7.1.1.2.4 



Unified Data Transport Inbound channel Header (C_UDTHU) UDT PDU 



C_UDT PDUs are sent by TS and MS. This PDU is a multi-block UDT conforming to the format specified in 
table 7.26. The number of UDT Appended data blocks is indicated by the Appended Blocks (UAB) information 
element. 
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NOTE: UDT Headers are transmitted by both TS and MS. 
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Table 7.26: Unified Data Transport Inbound channel Header PDU content 



Information element Length Remark 


Feature elements 


Elements defined in TS 102 361-1 [5] 


G/l (IG) 


1 


O2 = Destination is an individual MS address 


I2 = Destination is a Talkgroup address. Response not expected 


A 


1 


O2 = Response not expected if Destination is an individual MS 
address 


I2 = Response demanded if Destination is an individual MS 
address 


Reserved 


2 


OO2 


Format 


4 


IIIO2 


SAP 


4 


Service Access Point - OOOO2 for UDT 


UDT Format 


4 


Format of the data following the UDT Header 


Target address or Gateway 


24 




Source address or Gateway 


24 




Pad Nibble 


5 




Reserved 


1 




Appended_Blocks(UAB) 


2 


Number of Blocks appended to this UDT Header 
OO2 = 1 Appended Data UDT block 
OI2 = 2 Appended Data UDT blocks 
IO2 = 3 Appended Data UDT blocks 
1 12 = 4 Appended Data UDT blocks 


Supplementary_Flag(SF) 


1 


O2 = This UDT Header is carrying the data for a user initiated 

service (Short Data, Data Polling) 

I2 = This UDT Header is carrying supplementary data, supporting 

another tier III service. 


Protect Flag (PF) 


1 


Reserved for Future Use 


Opcode (UDTO) 


6 


Shall be set to 01 1011 2 


NOTE: Shaded rows are information elements that are defined in TS 102 361-1 [5]. 



7.1.1.3 



Outbound channel CSBKs transmitted on a Payload Channel by a TS 



7.1.1.3.1 



Channel Grant (P_GRANT) CSBK/MBC PDU 



Channel Grant PDUs transmitted on the payload channel conform to the same structure as channel grant PDUs 
transmitted on the TSCC. When transmitting such a PDU on the payload channel, the TS shall retain all PDUs to the 
value from the TSCC channel grant PDU except the logical channel number (and absolute frequency if the channel 
grant PDU has an appended CSBK block. 

The Payload Channel Grant PDU is transmitted by the TSCC either as a single block CSBK or a Multi Block Control 
(MBC). For the Physical Channel Number Information Element: 

a) If the value = 0000 0000 OOOO2 the Physical Channel number is invaUd. 

b) If the value = 0000 0000 0001 2 to 1 1 1 1 1111 1 1 IO2, the Physical Channel number represent a logical channel 

number for the physical transmitter and receiver frequency. The Private Data Channel Grant PDU is 
transmitted by the TSCC as a single block CSBK. 

c) If the value = 1111 1111 1111 2, the Physical Channel number defines a multi -block CSBK where the absolute 
transmitter and receiver frequency is defined in a second block concatenated to this block (defined in 

clause 7.1.1.1.2). 
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Table 7.27: Payload Channel Grant PDU Content 



Information element Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to 1 2 for a single block CSBK or O2 if this is a MBC header 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 11 0011 2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Logical Physical Channel 
Number 


12 


Payload Channel for the Call or an indicator that the absolute Tx & Rx 
frequency is specified in an appended CSBK block 


Logical Channel Number 


1 


O2 - TDMA channel 1 
I2-TDMA channel 2 


Reserved 


3 


OOO2 


Destination Address 


24 


Called party Individual MS Address, Gateway or Talkgroup 


Source address 


24 


Calling Party or Gateway 



7.1.1.3.2 



Clear (P_CLEAR) CSBK PDU 



Octet and 1 of the P_CLEAR CSBK PDU conforms to the LC format structure as defined in figure 7.1 in 
TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the P_Clear specific 
information shown in table 7.28. P_Clear is transmitted by the TS on a payload channel only and does not solicit a 
response. The P_Clear PDU is transmitted by the TS as a single block CSBK. 
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P BCAST 



P_AHOy 



P_ACK 

Acknowledgements 



Channel Grant 




P CLEAR 1 




P PROTECT 1 




MS Check 1 
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P ACK 1 
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P WACK 1 




P QACK 1 
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- 




—\ Talkqroup 1 1 






^ 


All Call 1 1 



Figure 7.21 



ETSI 



148 



ETSI TS 102 361-4 V1.2.1 (2006-09) 



Table 7.28: Clear PDU Content 



Information element 


Length 


Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to ^2 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shallbesetto10 11102 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Logical Physical Channel 
Number 


12 


Logical Physical Channel to which the MS shall move 


Reserved 


4 


OOOO2 


Target Address 


24 


Called party or MSI identifier 


Source Address 


24 


TSI 



7.1.1.3.3 



Protect (P_PROTECT) CSBK PDU 



Octet and 1 of the P_Protect CSBK PDU conforms to the LC format structure as defined in figure 7.1 in 
TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the P_Protect specific 
information shown in table 7.29. P_Protect is transmitted by the TS on a payload channel only and does not solicit a 
response. The P_Protect PDU is transmitted by the TS as a single block CSBK. 



CSBK 
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P AHOY 



P_ACK 

Acknow ledgements 



Channel Grar\i 




P CLEAR 1 




P PROTECT 1 




MS Check I 




Auth Challenqe 
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P ACK 1 




P NACK 1 




P WACK 1 




P QACK 1 



Individual 



Talkqroup 



All Call 



Figure 7.22 



Table 7.29: P Protect PDU content 



Information element 


Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to I2 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shallbesetto10 111l2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Reserved 


12 


0000 0000 OOOO2 


Protect Kind 


3 




IG 


1 




Target Address 


24 


MS Address or talkgroup 


Source Address 


24 


TSI 



7.1.1.3.4 



Ahoy (P_AHOY) CSBK PDU 



Octet and 1 of the AHOY CSBK PDU conforms to the LC format structure as defined in figure 7.1 in 
TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the P_AHOY specific 
information shown in table 7.20. The P_AHOY is transmitted by the TS on a payload channel and if addressed to a 
talkgroup does not solicit a response. 
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C5BK 
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Figure 7.23 



7.1.1.3.4.1 



MS Presence Check 



The TS may send a MS Presence Check P_AHOY on the payload channel to check if an individually addressed MS is 
present on the payload channel. 



7.1.1.3.4.2 



MS Authentication Check 



The TS may send a MS Authentication Check P_AHOY on the payload channel to challenge an MS. The MS 
Authentication Check uses a multi -block CSBK (two blocks). 



7.1.1.3.4.3 



Talkgroup Presence Check 



The TS may send a Talkgroup Presence Check P_AHOY on the payload channel to check if at least one talkgroup is 
present on the payload channel. 



7.1.1.3.5 



PAcknowledgement response 



Acknowledgement PDUs transmitted on the payload channel conform to the same structure as acknowledgement PDUs 
transmitted on the TSCC. 
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Figure 7.24 



7.1.1.4 



Inbound channel CSBKs transmitted on a Payload Channel by MS(s) 



7.1.1.4.1 



Random Access Request PDU 



Random Access PDUs transmitted on the payload channel conform to the same structure as Random Access PDUs 
transmitted on the TSCC. However the only random access Service _Kind permitted on the payload channel shall be to 
request an include service. 
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CSBK 



P_RAND 
Random Access 



Include 



P_ACK 
Acknowledgements 



iJl 



?_ACK 



P_MAINT 
Maintenance 



P_NACK 



P_DISC 



Figure 7.25 



7.1.1.4.2 



P_ACK Acknowledgements 



Acknowledgement PDUs transmitted on the payload channel conform to the same structure as acknowledgement PDUs 
transmitted on the TSCC. 



CSBK 



P_RAND 
Random Access 



Include 



P_ACK 
Acknow ledgements 



P ACK 



P_MAINT 
Maintenance 



P.NACK 



p_Disc: 



Figure 7.26 



7.1.1.4.3 



P MAINT Maintenance PDUs 



Octet and 1 of the P_MAINT CSBK PDU conforms to the LC format structure as defined in figure 7.1 in 
TS 102 361-1 [5] of the standard with the CSBKO replacing the FLCO. Octets 2 to 9 contain the P_MAINT specific 
information shown in table 7.30. P_MAINT is transmitted by MS on a payload channel only. The P_MAINT PDU is 
transmitted by MS as a single block CSBK. 



CSBK 



P_RAND 
Random Access 



P_ACK 
Acknow ledgen:\ents 



P_MAINT 
Maintenance 

Figure 7.27 
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Table 7.30: P MAINT PDU content 



Information element 


Length Remark 


Message dependent elements 


Last block (LB) 


1 


This bit shall be set to ^2 


Protect Flag (PF) 


1 




Feature elements 


CSBK Opcode (CSBKO) 


6 


Shall be set to 10 101 O2 


Feature set ID (FID) 


8 


Shall be set to 0000 OOOO2 


Reserved 


12 




Maint Kind 


3 




Reserved 


1 




Target Address 


24 


TSI 


Source Address 


24 


MS Address 



7.1 .2 Short Link Control PDUs 



7.1.2.1 



Systenn Paranneters 



Bits to 3 of Octet of the System Parameters (S YS_Parms) Short LC PDU conform to the Short LC format structure 
as defined in figure 7.2 of clause 7.1 in TS 102 361-1 [5]. Octets 1 to 3 contain the System Parameters specific 
information. The SYS_Parms PDU is shown in table 7.31. 

Table 7.31 : SYS Parms PDU Content 



Information element Length Value Remark 


Elements 


Short LC Opcode (SLCO) 


4 


001 O2 




MODEL 


2 


OO2 


Tiny Network Model 


OI2 


Small Network Model 


IO2 


Large Network Model 


II2 


Huge Network Model 


NET 


12 




Network and Site Definition 


SITE 


Reg 


1 


O2 


This TSCC does not require the MS to register 
before becoming active 


I2 


This TSCC requires the MS to register before 
becoming active 


Common Slot Counter 


9 




Common Slot Counter 


NOTE: Compressed algorithm is the same as the short LC CRC calculation algorithm as defined in 
clause B.3.8 of TS 102 361-1 [5]. 



7.2 Layer 3 information element coding 

The following clauses contain descriptions of the information elements contained within layer 3 PDUs, and provide a 
description of what the elements represent in relation to their bit representation. The structure of the tables is as follows: 

• the information element column gives the name of the element; 

• the element length column defines the length of the element in bits; 

• the value column denotes fixed values or a range of values; 

• the remarks column defines the meaning of the information element against each of its bit represented values. 
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7.2.1 Mask 

The Mask information element has a length of 5 bits and is shown in table 7.32. 

Table 7.32: Mask 



Information element 


Length 


Value 


Remark 


Mask 


5 


0to24 


Value in the range to 24 (decimal) 



7.2.2 Service Function 

The Service Type information element has a length of 2 bits and is shown in table 7.33. 

Table 7.33: Service Function 



Information element 


Length 


Value 


Remark 


Service Function 


2 


OO2 


Random Access invited for all Services 


OI2 


Random Access Invited for Services that require a 

payload channel 

Random Access Invited for registration requests 


IO2 


Random Access Invited for Services that do not 

require a payload channel 

Random Access Invited for registration requests 


II2 


Random Access invited for random access 
registration requests only 



7.2.3 NRand_Wait 

The Nrand_Wait information element has a length of 4 bits and is shown in table 7.34. The TSCC shall specify, using 
NRand_Wait, the delay (in TDMA-frames) a MS must wait before deciding to retransmit and choose another slot from 
a new random-access-frame. 

Table 7.34: NRand Wait 



Information element 


Length 


Value 


Remark 








TSCC response to a Random Access Request 








= response in the next TDMA-frame 








1 - MS shall wait for 1 TDMA frame 








2 - MS shall wait for 2 TDMA frames 








3 - MS shall wait for 3 TDMA frames 








4 - MS shall wait for 4 TDMA frames 








5 - MS shall wait for 5 TDMA frames 








6 - MS shall wait for 6 TDMA frames 


NRand_Wait 


4 


0to15 


7 - MS shall wait for 7 TDMA frames 

8 - MS shall wait for 8 TDMA frame 

9 - MS shall wait for 9 TDMA frames 

1 - MS shall wait for 1 TDMA frames 

11 - MS shall wait for 1 1 TDMA frames 

1 2 - MS shall wait for 1 2 TDMA frames 

1 3 - MS shall wait for 1 3 TDMA frames 

1 4 - MS shall wait for 1 5 TDMA frames 

1 5 - MS shall wait for 24 TDMA frames 
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Table 7.35: Reg 
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Information element 


Length 


Value 


Remark 


Reg 


1 


O2 


MSs are not required to register 


I2 


IVISs are required to register 



7.2.5 Backoff 

The Backoff information element has a length of 4 bits and is shown in table 7.36. 

Table 7.36: Backoff Number 



Information element 


Length 


Value 


Remark 


Backoff 


4 





- Reserved 


1 


Backoff TDIVIA Frame length = 1 


2 


Backoff TDIVIA Frame length = 2 


3 


Backoff TDMA Frame length = 3 


4 


Backoff TDMA Frame length = 4 


5 


Backoff TDMA Frame length = 5 


6 


Backoff TDMA Frame length = 8 


7 


Backoff TDMA Frame length = 1 1 


8 


Backoff TDMA Frame length = 15 


9 


Backoff TDMA Frame length = 20 


10 


Backoff TDMA Frame length = 26 


11 


Backoff TDMA Frame length = 33 


12 


Backoff TDMA Frame length = 41 


13 


Backoff TDMA Frame length = 50 


14 


Backoff TDMA Frame length = 70 


15 


Backoff TDMA Frame length = 100 



7.2.6 System Identity Code 

The System Identity Code information element has a length of 16 bits and is shown in table 7.37. 

Table 7.37: System Identity Code 



Information element 


Length 


Value 


Remark 


System Identity Code 
C SYScode 


16 


value 


System identity Code transmitted on the TSCC 



7.2.7 Responsejnfo 

The Responsejnfo information element contains supplementary information in acknowledgement PDUs. It has a 
length of 7 bits and is shown in table 7.38. 

Table 7.38: Responsejnfo 



Information element Length Alias/value 


Remark 


Acknowledgement Reason Code = Message_Accepted (0100 OOOO2) 


Responsejnfo 


7 


PowerSAve_Offset 


Acknowledgement to a random access 
registration request that invokes power 
save (see clause 6.4.7) 


All other acknowledgement Reason Codes 


Responsejnfo 


7 


000 OOOO2 


Reserved 
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7.2.8 Reason 

The Reason information element has a length of 8 bits and is shown in tables 7.39 to 7.42. Separate tables are shown for 
the classifications C_ACK, C_NACK, C_QACK, C_WACK. 

Table 7.39: Answer Response C_ACK 



Information 
element 


Length 


Value Alias Remark 


Acknowledgement Transmitted by a TS 
Message Accepted by the MS 


Reason 


8 


OIOOOOOO2 


Message_Accepted 


Message accepted by TS - Proceed 


0100 0001 2 


Store_Forward 


Call is placed in store and forward buffer for 
onward transmission when the called MS 
registers. 


0100 001 O2 


Reg_Accepted 


Request from MS to register has been 
accepted 


010000112 


Call-Back 


Called Party will call back 


Acknowledgement Transmitted by a MS 
Message Accepted by the TS 


OIOOOIOO2 


MS_Accepted 


Message accepted by MS 


OIOOOIOI2 


CallBack 


Called MS is indicating to the TS that it will 
call back later 



ETSI 



155 



ETSI TS 102 361-4 V1.2.1 (2006-09) 



Table 7.40: Answer Response C_NACK 



Information 
element 



Length 



Value 



Mnemonic 



Remark 



Message/Service rejected by network (TS) 



Reason 



0010 0001. 



0010 001 Oo 



0010 0011. 



0010 0100^ 



00100101. 



OOlOOIlOo 



00100111. 



OOlOIOOOo 



0010 1001. 



0010 1 01 Oo 



00101011. 



0010 1100:, 



001011012 



Not_Supported 



Perm User Refused 



Temp_User_Refused 



Transient_Sys_Refused 



NoregMSaway_Refused 



MSaway_Refused 



Div Cause Fail 



SYSbusy_Refused 



SYS_NotReady 



Call Cancel Refused 



Reg_Refused 



Reg_Denied 



IP Connection failed 



Network does not support this service 



Request refused because service has 
not been authorized for this user 
(permanent) (Meaning of permanent 
is manufacturer specific) 



Request refused because service is 
not currently authorized for this user 
(temporary) (Meaning of temporary is 
manufacturer specific) 



Request refused because the service 
is not available to this network at this 
time 



Request refused because called party 
is not in radio contact (and is not 
registered with the network) 



Request refused because called party 
is not in radio contact (but is 
registered with the network) 



Call cannot be processed because 
the MS has diverted its calls 



Request refused because the network 
is experiencing congestion (Network 
Overload) 



Request refused because the network 
is not ready (try later) 



Request to cancel a caW has been 
refused i.e. the call may still mature 



Request from a MS to register has 
been refused 



Request from a MS to register has 
been denied 



Request from a MS to inform IP 
connection advice failed 



OOIOIIOO0 



0010 1101. 



OOIOIIIO0 



00101111. 



0011 OOOOo 



0011 0001. 



Message/Service rejected by MS 



MSNot_Supported 



LineNot_Supported 



StackFull Refused 



EuipBusy_Refused 



Recipient_Refused 



Custom Refused 



MS does not support this service or 
feature 



Request refused because service is 
not supported by the called party 
(Line) 



Request refused because the called 
party's internal call stack is full and is 
not employing a FIFO 



Request refused because called party 
ancillary equipment is busy 



Request refused by called party user 
(like in FOACSU) 



Request refused due to custom- 
defined reason 



Table 7.41 : Answer Response C_QACK 



Information 
element 


Length 


Value Alias Remark 


Acknowledgement Transmitted by a TS 


Reason 


8 


IOOOOOOO2 


Queued-for-channel 


Message accepted by TS - more signalling to 
follow 


1000 0001 2 


Queued-for-busy 
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Table 7.42: Answer Response C_WACK 



Information 
element 


Length 


Value Alias Remark 


Acknowledgement Transmitted by a TS 


Reason 


8 


IIOOOOOO2 


Wait 


IVIessage accepted by TS - more signalling to 
follow 



7.2.9 Source Type 

The Source Type information element has a length of 1 bit and indicates the entity that transmitted the PDU. The 
Source Type is shown in table 7.43. 

Table 7.43: Source Type 



Information 
element 


Length 


Value 


Alias 


Remark 


Source Type 


1 


O2 




The PDU is transmitted by the TS 


I2 




The PDU is transmitted by the MS 



7.2.10 Digits 

The Digits information element represents dialled digits coded as table 7.44. 

Table 7.44: Digits 



Information 
element 


Length 


Value 


Alias 


Remark 


Digits 


4 


OOOO2 


Digit '0' 




0001 2 


Digit '1' 




001 O2 


Digit '2' 




00112 


Digit '3' 




01002 


Digit '4' 




01012 


Digit '5' 




01102 


Digit '6' 




01112 


Digit 7' 




10002 


Digit '8' 




10012 


Digit '9' 




10102 


Digit '*' 


* character 


10112 


Digit '#' 


# character 


11002 


Reserved 




11012 


Reserved 




11102 


Reserved 




11112 


Digit 'NULL' 





7.2.1 1 Active_Connection 

This information element specifies if the TS has an active network connection with the rest of the network, 
i.e. communication with other radio sites is possible. 

Table 7.45: Active Connection 



Information element 


Length 


Value 


Alias 


Remark 


Active Connection 


1 


O2 




O2 - The TS does not have a connection with the 
network 


I2 




I2 - The TS has a connection with the network 
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7.2.12 Packet Mode 

The Packet Mode information element has a length of 1 bit and is shown in table 7.46. 

Table 7.46: Packet Mode 



Information element 


Length 


Value 


Alias 


Remark 


Packet Mode 


1 


O2 




O2 - Payload Channel uses 2:1 mode 


I2 




I2 - Payload Channel uses 1 :1 mode 



7.2.13 Service_Kind 

The Service_Kind information element has a length of 4 bits and is shown in table 7.47. 

Table 7.47: Service Kind information element 



Information element 


Length 


Value 


Remark 


Service_Kind 


4 


OOOO2 


Individual Voice Call Service (Include Voice Individual 
Call Service if sent on a payload channel) 


0001 2 


Talkgroup Voice Call Service (Include Voice Talkgroup 
Call Service if sent on a payload channel) 


001 O2 


Individual Packet Data Call Service 


00112 


Packet Data Call Service to a talkgroup 


01002 


Individual Short Data Call Service 


01012 


Talkgroup Short Data Call Service 


01102 


Short Data Polling Service 


01112 


Status Transport Service 


10002 


Call Diversion Service 


100l2to11002 


Reserved 


11012 


Supplementary Service 


11102 


Registration or Authentication Service (and deregistration) 


11112 


Cancel Call Service 



7.2.13.1 Service_Kind_Flag 

The Service_Kind_Flag information element has a length of 1 bit and is shown in table 7.48. The meaning of 
Service_Kind_Flag supports the Service_Kind information element. The meaning of the Service_Kind_Flag depends on 
the value of Service_Kind. 

Table 7.48: Service_Kind_Flag information element 



Information element 


Length 


Value 


Remark 


Service_Kind_Flag 


1 


O2 





7.2.14 Service_Options 



The number of Service_Options that are applicable is dependent on the DMR service requested. The Service_Options 
information element has a length of 7 bits and is shown for each applicable service in figures 7.2.14.1 to 7.2.14.5. 

7.2.1 4.1 Service_Options for a Voice, Packet Service Request 

The Service_Options information for the Voice, Packet Data and Short Data Service request is shown in table 7.49. 
• The Emergency Service information element is applicable to voice and packet data calls. 



ETSI 



158 



ETSI TS 102 361-4 V1.2.1 (2006-09) 



The Broadcast Service information element is applicable to voice talkgroups. 

The OVCM information element is applicable to voice calls. 

The Priority Service information element is applicable to any call that may be queued on the TSCC. 

The Supplementary Data information element is applicable to all tier III services. 

Table 7.49: Service_Options for Voice/Packet Service Request 



Information element 


Length 


Value 


Remark 


Emergency 




O2 


Non-emergency service 


I2 


Emergency service 


Privacy 




O2 


See note 1 


Supplementary Data 




O2 


No Supplementary Data Transfer Service required for 
this call 


I2 


Supplementary Data Transfer Service requested for 
this call 


Broadcast 




O2 


Non-broadcast service 


I2 


Broadcast service (see note 3) 


Open Voice Call Mode (OVCM) 




O2 


Non-OVCM call 


I2 


OVCM call 


Priority level 


2 


OO2 


No priority 


OI2 


Priority 1 (see note 2) 


IO2 


Priority 2 (see note 2) 


II2 


Priority 3 (see note 2) 


NOTE 1 : Privacy is not defined in the present document. 
NOTE 2: Priority 3 is the highest priority. 
NOTE 3: Broadcast is applicable to talkgroups. 



7.2.14.2 Service_Options for a Call Diversion Service Request 

The Service_Options information for the call diversion Service request is shown in table 7.50. The Divert Kind 
information element determines to which call service the call diversion shall be applicable. 

Table 7.50: Service_Options for Call Diversion Service Request 



Information element 


Length 


Value 


Remark 


Emergency 


1 


O2 


Not applicable 


Privacy 


1 


O2 


See note 


Divert Set/Clear 


1 


O2 


Clear Call Diversion 


I2 


Set Call Diversion 


Divert Kind 


1 


Active 1 2 
Inactive O2 


Divert applicable to Voice Calls 


1 


Divert applicable to Packet Data Calls 


1 


Divert applicable to Short Data Calls 


1 


Divert applicable to Status Calls 


NOTE: Privacy is not defined in the present document. 



7.2.14.3 Service_Options for a Registration Service Request 

The Service_Options information for the registration service request is shown in table 7.51. There are no applicable 
service options for a registration service request. 
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Table 7.51 : Service_Options for the Registration Service 



Information element 


Length 


Value 


Remark 


Reserved 


1 


O2 




Privacy 


1 


O2 


See note 


IPJnform 


1 


O2 


IVIS is not advising IP connection 


I2 


IVIS is advising IP connection 


PowerSave_RQ 


3 


OOO2 


Power Save not requested 


001 2 to 
III2 


Power Save requested 


Reg_Dereg 


1 


O2 


If IP_lnform=02 the IVIS is attempting to de-register 
If IP_lnform=l2the IVIS is deleting an IP connection 


I2 


If IP_lnform=02 the MS is attempting to register 

If IP_lnform=l2the MS is attempting to register and/or adding 

an IP connection 


NOTE: Privacy is not defined in the present document. 



7.2.14.4 Service_Options for an Include Call Service Request 

The Service_Options information for the include service request is shown in table 7.52. Include call service requests 
shall be restricted to the payload channel. There are no applicable service options for a registration service request. 

Table 7.52: Service_Options for the Registration Service 



Information element 



Length 



Value 



Remark 



Reserved 



Privacy 



See note 



Reserved | 5 | OOOO2 

NOTE: Privacy is not defined in the present document. 



7.2.1 4.5 Service_Options for a Status Transfer Request 

The Service_Options information for the include service request is shown in table 7.53. Include call service requests 
shall be restricted to the payload channel. There are no applicable service options for a registration service request. 

Table 7.53: Service_Options for the Status Transport Service 



Information element 


Length 


Value 


Remark 


status 


7 


Value 


Status value to be transported 



7.2.15 Service_Options_Mirror 

The Service_Options_Mirror information element is transmitted in C_AHOY PDUs. 

If the C_AHOY PDU has been transmitted as an immediate (or delayed) acknowledgement to a C_RAND Service 
request, the Service_Options_Mirror is set to the Service_Options information element from the C_RAND PDU. 

7.2.1 5.1 Service_Options_Mirror for MS Authentication 

If the C_AHOY PDU has been transmitted as the result of a polling PDU from the TSCC for Authentication, then the 
Service_Option_Mirror shall be set to the values specified in table 7.54. 
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Table 7.54: Service_Options_Mirror for MS Authentication Poll 



Information element 


Length 


Value 


Remark 


Service_Options_Mirror 


Reserved 


1 


O2 




Privacy 


1 


O2 


See note 


Reserved 


5 


OOOO2 




NOTE: Privacy is not defined in the present document. 



7.2.1 5.2 Service_Options_Mirror for MS Stun/Revive 

If the C_AHOY PDU has been transmitted as the result of a polHng PDU from the TSCC for MS stun/revive then the 
Service_Option_Mirror shall be set to the values specified in table 7.55. 

Table 7.55: Service_Options_Mirror for MS Stun/Revive Poll 



Information element 


Length 


Value 


Remark 


Reserved 


1 


O2 




Privacy 


1 


O2 


See note 


Stun_Revive 


1 


O2 


Action by the IVIS is Revive 


I2 


Action by the IVIS is Stun 


Reserved 


4 


OOOO2 




NOTE: Privacy is not defined in the present document. 



7.2.16 Proxy Flag 

For calls to destinations connected through a TS gateway, the proxy flag indicates the number of Appended Data UDTs 
needed to upload the address of the final destination. For a call to a PABX or the PSTN, one appended data UDT will 
carry up to 20 dialled digits and two appended data UDTs will carry up to 44 dialled digits. 

Table 7.56: Proxy Flag information element 



Information element 


Length 


Value 


Remark 


Proxy Flag 


1 


O2 


Number of appended data MBCs needed to upload 
the final destination address = 1 
Number of Extended BCD digits for addressing 
through a PSTN/PABX gateway = 1 to 20. For IP 
gateway extended address is IPV4 


I2 


Number of appended data UDTs needed to upload 
the final destination address = 2 
Number of Extended BCD digits for addressing 
through a PSTN/PABX gateway = 21 to 44. For IP 
gateway extended address is IPV6Number 
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7.2.17 POL_FMT 

Specifies the format of polled data from the Short Data Polling procedures specified in clause 6.6.5.3. 

Table 7.57: POL FMT information element 



Information 
element 


Length 


Value 


Remark 


POL_FMT 


4 


OOOO2 


Binary 


0001 2 


MS Addresses 


001 O2 


4 bit BCD 


00112 


ISO 7 bit character set (ISO/IEC 646 [11]) 


01002 


ISO 8 bit character set (ISO/IEC 8859 [12]) 


01012 


NIVIEA location information 


01102 


IP address 


01112 


16 bit Unicode characters 


10002 


Reserved 


10012 


Reserved 


10102 


Reserved 


10112 


Reserved 


11002 


Reserved 


11012 


Reserved 


11102 


Reserved 


11102 


Reserved 



7.2. 1 8 Appended_ Block 

If the Supplementary Data Service has been invoked as an option with other voice or data services, the Appended 
Supplementary Data information element is used to pass the number of Appended Data UDTs needed to upload the 
Supplementary Data. 

If the Short Data Service has been invoked, the Appended Short Data information element is used by an MS to pass the 
number of Appended Data UDTs needed to upload the Short Data. 

Table 7.58: Appended Supplementary Data information element 



Information element 


Length 


Alias 


Value 


Remark 


Appended_Block 


2 


UAB 


OO2 


Number of appended data UDTs needed to upload 
the supplementary data = 1 


OI2 


Number of appended data UDTs needed to upload 
the supplementary data = 2 


IO2 


Number of appended data UDTs needed to upload 
the supplementary data = 3 


II2 


Number of appended data UDTs needed to upload 
the supplementary data = 4 



7.2.19 Opcode 

The Opcode information element specifies the function of a UDT Header. 

Table 7.59: Opcode 



Information element 


Length 


Value 


Remark 


Opcode 


6 


00 OOOO2 


MBC is a UDT header 


00 0001 2 
toll IIII2 


Reserved 
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7.2.20 Announcement type 

The Announcement type Format Code information element has a length of 5 bits and is shown in figure 7.2. 

Table 7.60: Announcement type 



Information element 


Length 


Value 


Alias 


Remark 


Announcementjype 


5 


OOOO2 


Ann-WD_TSCC 


Announce/Withdraw TSCC 


0001 2 


CallTimer_Parms 


Specify Call Timer Parameters 


000102 


Vote_Now 


Vote Now Advice 


000112 


Local_Time 


Broadcast Local Time 


001002 


MassReg 


Mass_Registration 


001012 


Chan_Freq 


Announce a logical channel / frequency 
relationship 


001102 


Adjacent_Site 


Adjacent Site information 


0011l2to1 
IIOI2 




Reserved 


1 IIIO2 




Manufacturer Specific 


1 IIII2 




Manufacturer Specific 



7.2.20.1 Announce/Withdraw TSCC (Ann-WD_TSCC) 

Table 7.61 : Announce/Withdraw TSCC 



Information 
element 


Length 


Value 


Alias 


Remark 


Broadcast 
Farms 1 


4 


O2 




Reserved 


4 


Value 




Colour code for CH_1 (default=00002) 


4 


Value 




Colour Code for CH_2 (default=00002) 


1 


O2 


AW_FLAG1 


AddBCAST_CH1 to hunt list 


I2 




Withdraw BCAST_CH1 from hunt list 


1 


O2 


AW_FLAG2 


Add BCAST_CH2 to hunt list 


I2 




Withdraw BCAST_CH2 from hunt list 


Broadcast 
Farms 2 


12 


or 1 to 
4095 


BCAST_CH1 


CHNULL or Logical Physical Channel Number 


12 


or 1 to 
4095 


BCAST_CH2 


CHNULL or Logical Physical Channel Number 



7.2.20.2 Specify Call Timer Parameters (CallTimer_Parms) 

Table 7.62: Specify Call Timer Parameters 



Information 
element 


Length 


Value 


Alias 


Remark 


Broadcast 
Farms 1 


9 


O2 


T_EMERG_TIMER 


MS uses its Internal Emergency Timer 


1 to 510 


Call Timer for Emergency Calls 


511 


Emergency Call Timer is Infinity 


5 





T_PACKET_TIMER 


MS uses its Internal Packet Timer 


1 to 30 


Call Timer for Packet Data 


31 


Packet Call Timer is Infinity 


Broadcast 
Farms 2 


12 





T_MS-MS_TIMER 


MS uses its Internal Timer for MS-MS calls 


1 to 4 094 


Call Timer for MS-MS Calls 


4 095 


MS-MS Call Timer is Infinity 


12 





T_MS-LINE_TIMER 


MS uses its Internal Timer for line connected calls 


1 to 4 094 


Call Timer for Line Connected calls 


4 095 


Line Connected Call Timer is Infinity 
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7.2.20.3 Vote Now Advice (Vote_Now) 

Table 7.63: Vote Now Advice 



Information 
element 


Length 


Value 


Alias 


Remark 


Broadcast 
Parms 1 


14 






Most Significant 14 bits of the System Identity 
Code of the TSCC being assessed 


Broadcast 
Parms 2 


12 


0000 0000 OOOO2 




Reserved 


12 


1 to 4095 


CH VOTE 


Physical Channel Number to be assessed 



7.2.20.4 Broadcast Local Time (Local_Time) 



Table 7.64: Broadcast Local Time 



Information 
element 


Length 


Value 


Alias 


Remark 


Broadcast 
Parms 1 


5 




B_DAY 


Day of the Month 1 to 31 (or if date is not being 
broadcast) 


4 




B_MONTH 


Month 1 to 12 (or if month is not being 
broadcast) 


5 




UTC_OFFSET 


Offset between local time and UTC time (as a 
two's complement number in the range -12 to +12 
(or 1 1 1 1 12 if offset is not being broadcast)) 


Broadcast 
Parms 2 


5 




B HOURS 


Hours to 23 


6 




B MINS 


Minutes to 59 


6 




B SECS 


Seconds to 59 


3 




DAYOF WEEK 


The day of the week (or if the day of week is not 
being broadcast) 


4 


OOOO2 




Reserved 



The information element meaning of B_MONTH and DAYOF_WEEK values are specified in tables 7.65 and 7.66. 



7.2.20.4.1 



Broadcast Local Time - Month (B_MONTH) 



Table 7.65: B MONTH information element 



Information 
element 


Length 


Value 


Remark 


B_MONTH 


4 


OOOO2 


<Month not broadcast> 


0001 2 


January 


001 O2 


February 


00112 


March 


01002 


April 


01012 


May 


01102 


June 


01112 


July 


10002 


August 


10012 


September 


10102 


October 


10112 


November 


11002 


December 
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7.2.20.4.2 Broadcast Local Time - Day of Week (DAYSOF_WEEK) 

Table 7.66: DAYSOF WEEK information element 



Information 
element 


Length 


Value 


Remark 


DAYSOF_WEEK 


3 


OOO2 


<Days of Week not broadcast> 


OOI2 


Sunday 


01 O2 


Monday 


OII2 


Tuesday 


IOO2 


Wednesday 


IOI2 


Thursday 


IIO2 


Friday 


III2 


Saturday 



7.2.20.5 Broadcast Mass Registration (MassReg) 

Table 7.67: Mass Registration 



Information 
element 


Length 


Value 


Alias 


Remark 


Broadcast 
Parms 1 


5 


OOOO2 




Reserved 


4 






Reg Window 


5 






Aloha IVIask 


Broadcast 
Parms 2 


24 






NULL or IVIS Individual Address 



7.2.20.5.1 



Reg_Window 



Table 7.68: Reg_Window 



Information 
element 


Length 


Value 


Treg_Window 


Remark 


Reg_Window 


4 







<Cancel Mass Registration> 


1 


.5 


Values in Seconds 


2 


1 


3 


2 


4 


5 


5 


10 


6 


20 


7 


30 


8 


100 


9 


300 


10 


1 000 


11 


3 000 


12 


10 000 


13 


30 000 


14 


100 000 


15 


200 000 
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7.2.20.6 Broadcast logical/absolute frequency relationship 

Table 7.69: Broadcast logical/absolute frequency relationship information element 



Information 
element 


Length 


Value 


Alias 


Remark 


Broadcast 
Parms 1 


5 


OOOO2 




Reserved 


4 






Reg Window 


5 






Aloha Mask 


Broadcast 
Parms 2 


24 






NULL or MS Individual Address 



7.2.20.7 Broadcast Adjacent Site information 

Table 7.70: Broadcast Adjacent Site information 



Information 
element 


Length 


Value 


Alias 


Remark 


Broadcast 
Parms 1 


14 






Most significant 14 bits of the C_SYScode 


Broadcast 
Parms 2 


1 






Active Connection 


23 






Reserved 



7.2.20.8 



CdefParms 



Table 7.71 : CdefParms information element Definition 



CdefParms 


Information element 


Length 1 Value 


Alias 


Remark 


CdefParms 


Cdeftype=00002 


Logical Physical 
Channel Number 


12 




CHAN 




Absolute transmitter 
frequency - integer MHz 


10 




TXMHz 


Absolute transmitter frequency - 
integer MHz 


Absolute transmitter 
frequency 


13 




TXKHz 


Part transmitter MHz in 250Hz 
steps 


Absolute receiver 
frequency - integer MHz 


10 




RXMHz 


Absolute transmitter frequency - 
integer MHz 


Absolute receiver 
frequency 


13 




RXKHz 


Part receiver MHz in 250Hz 
steps 




CdefParms 


Cdeftype=000l2to 
IIII2 




58 


Reserved 



The mechanism for calculating the absolute frequency is defined in annex C. 

7.2.21 Individual/Group (IG) 

Table 7.72: IG information element Definition 



Information 
element 


Length 


Value 


Alias 


Remark 


IG 




O2 


G/l 


The Target Address information element in the 
PDU represents an individual MS address 


I2 


The Target Address information element in the 
PDU represents a talkgroup 
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7.2.22 Protect Kind 



Table 7.73: Protect Kind information element Definition 



Information 
element 


Length 


Value 


Alias 


Remark 


Protect_Kind 


3 


OOO2 


DIS_PTT 


Disable Target MS or Talkgroup 
transmission 


OOI2 


EN_PTT 


Enable Target MS or Talkgroup transmission 


01 O2 


ILLEGALLY_PARKED 


Clear down from the payload channel, MS 
whose address does not match Source or 
Target Address 


OII2 




Reserved 


IOO2 




Reserved 


IOI2 




Reserved 


IIO2 




Reserved 


III2 




Reserved 



7.2.23 Maint Kind 



Table 7.74: Maint Kind information element Definition 



Information 
element 


Length 


Value 


Alias 


Remark 


Maint_Kind 


3 


OOO2 


DISCON 


Disconnect. End of payload channel use 


OOI2 




Reserved 


01 O2 




Reserved 


OII2 




Reserved 


IOO2 




Reserved 


IOI2 




Reserved 


IIO2 




Reserved 


III2 




Reserved 



7.2.24 Response expected (A) 



Table 7.75: A information element Definition 



Information 
element 


Length 


Value 


Alias 


Remark 


A 


1 


O2 




Response not expected 


I2 




Response expected 
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7.2.25 Format 



Table 7.76: Format information element 



Information 
element 


Length 


Value 


Remark 


Format 


4 


OOOO2 


Reserved 


0001 2 


Reserved 


001 O2 


Reserved 


00112 


Reserved 


01002 


Reserved 


01012 


Reserved 


01102 


Reserved 


01112 


Reserved 


10002 


Reserved 


10012 


Reserved 


10102 


Reserved 


10112 


Reserved 


11002 


Reserved 


11012 


Reserved 


11102 


UDT header for UDT 


11102 


Reserved 



7.2.26 Service Access Point (SAP) 



Table 7.77: SAP information eiement 



Information 
element 


Length 


Value 


Remark 


SAP 


4 


OOOO2 


UDT 


0001 2 


See TS 102 361-1 [5] 


001 O2 


See TS 102 361-1 [5] 


00112 


See TS 102 361-1 [5] 


01002 


See TS 102 361-1 [5] 


01012 


See TS 102 361-1 [5] 


01102 


See TS 102 361-1 [5] 


01112 


See TS 102 361-1 [5] 


10002 


See TS 102 361-1 [5] 


10012 


See TS 102 361-1 [5] 


10102 


See TS 102 361-1 [5] 


10112 


See TS 102 361-1 [5] 


11002 


See TS 102 361-1 [5] 


11012 


See TS 102 361-1 [5] 


11102 


See TS 102 361-1 [5] 


11102 


See TS 102 361-1 [5] 



7.2.27 Pad Nibble (PN) 

The PN information element specifies the number of pad nibbles which have been appended to the data to form an 
integer number of blocks. The number of pad nibbles for each of the UDT data formats is specified in annex B. 
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Table 7.78: Pad Nibble 



Information element 


Length 


Value 


Remark 


Pad Nibble 


5 


Value 


Number of pad nibbles appended to the data 



7.2.28 UDT Format 

Specifies the format of the user or system data carried in UDTs for the UDT mechanism. 

Table 7.79: UDT Format information element 



Information 
element 


Length 


Value 


Remark 


UDT Format 


4 


OOOO2 


Binary 


0001 2 


MS Address 


001 O2 


4 bit BCD 


00112 


ISO 7 bit character set (ISO/IEC 646 [11]) 


01002 


ISO 8 bit character set (ISO/IEC 8859 [12]) 


01012 


NMEA location coded (lEC 61162-1 [8]) 


01102 


IP address 


01112 


16 bit Unicode characters 


10002 


Custom Coded (manufacturer specific) 


10012 


Custom Coded (manufacturer specific) 


10102 


Reserved 


10112 


Reserved 


11002 


Reserved 


11012 


Reserved 


11102 


Reserved 


11112 


Reserved 



7.2.29 Offset 

On the outbound channel, specifies if the payload channel shall use offset or aligned timing. 

Table 7.80: Offset information element 



Information 
element 


Length 


Value 


Remark 


Offset 


1 


O2 


The payload channel shall use aligned timing 


I2 


The payload channel shall use offset timing 
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Annex A (normative): 

Timers, constants levels and addresses 

This annex lists the timers and constants in a DMR MS. 

Where indicated, a value should be chosen from within the specified range. For other timers and constants, a default 
value may be specified and the value of these timers and constants shall be configurable within the DMR entity (MS, 
BSorTS). 



A.1 Layers timers 



Table A.1 : Layer 3 Timers 



Mnemonic 




Value 


Description 


Trand TC 


- 


2 to 60 seconds 


Timeout for IVIS attempting Random Access 


T_Nosig 


- 


1 to 15 seconds 


Timeout for entering hunting procedures if no TSCC is 
received 


T_EMERG_TIMER 




1 to 510 


Emergency Timer in steps of 30 seconds 
(e.g. 1 = 30 seconds, 2 = 60 seconds, etc.) 


511 


Emergency Timer is Infinity 


T_PACKET_TIMER 


- 


1 to 30 


Packet Timer in steps of 5 seconds 


31 


Packet Timer is Infinity 


T_MS-MS_TIMER 




1 to 4 094 


IVIS-IVIS Timer in steps of 10 seconds (e.g. 1=10 seconds, 
2 = 20 seconds, etc.) 


4 095 


IVIS-IVIS Timer is Infinity 


T_MS-LINE_TIMER 




1 to 4 094 


MS-Line Timer in steps of 10 seconds (e.g. 1=10 seconds, 
2 = 20 seconds, etc.) 


4 095 


MS-Line Timer is Infinity 


TP_Timer 


- 


4 to 60 seconds 


Timeout for a calling MS waiting for a call that requires a 
payload channel 










TNP_Timer 


- 


2 to 20 seconds 


Timeout for a calling MS waiting for a call that does not 
require a payload channel 










T_Awake 


- 


0.1 to 60 seconds 


Time MS stays awake after receiving a PDU (in steps of 
0,1 seconds) 


TV Hangtime 


- 


1 to 60 seconds 


Payload Voice Hangtime timer 


TV Item 


- 


1 to 60 seconds 


Payload Voice Maximum Item Timer 


TV Inactive 


- 


to 20 seconds 


Payload Voice Inactivity Timer 


TD Inactive 


- 


to 20 seconds 


Payload Data inactivity Timer 


TD Item 


- 


1 to 60 seconds 


Payload Packet Data Maximum Item Timer 


T Pending 


- 


2 to 60 seconds 


Timeout for called MS after receiving AHOY 


T dereg 


- 


0,2 to 2 seconds 


Timer to de-register before abandon in 0,1 second steps 


T_BS_lnactive 


- 


1 to 300 seconds 


Timer to hibernate if no inbound activity on an unregulated 
TSCC 


T_DENREG 







The denied registration timer is inactive 


1 to 1 000 


Denied registration lifetime in steps of 10 seconds 
(e.g. 1=10 seconds, 2 = 20 seconds, etc.) 
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A.2 Layer 3 constants 



Table A.2: Layer 3 Constants 



Mnemonic 




Value 


Description 


NDefault NW 


- 


5 


NRand Wait at MS switch on 


NRand_NR 


- 


6 


Number of random access attempts for a normal and high 
priority service 


NRand_NE 


- 


10 


Number of random access attempts for a emergency priority 
service 


N_Maint 


- 


4 


Number of P_MAINT PDUs transmitted by an MS to clear 
down the payload channel 










Nmax Ch 


- 


50 


Minimum Number of channels in Short Hunt List 


Low Comp Ch 


- 


1 to 4 095 


Lowest logical channel in use by the network 


High_Comp_Ch 


- 


Low Comp Ch 
to 4 095 


Highest logical channel in use by the network 


Comp Flag 


- 


True/False 


Suppress Comprehensive Hunt (see annex D) 


NSYSerr 


- 


1 to 3 


Number of C_SYScodes received that differ from the value 
verified 


DMRLA 


- 


Oto10 


Length of SYS_AREA information field from the C_SYScode 



A.3 Layer 3 levels 



Table A.3: Layer 3 signal levels 



Mnemonic 




Value 


Description 


L_Upper_SHort 


- 


Units and values 
are manufacturer 
specific 


The threshold of signal quality above which will be sampled 
first in a short hunt 


L_Lower_SHort 


- 


The threshold of signal quality below which the MS shall be 
unable to become active 


L_Squelch 




Signal level (or equivalent) below which physical channels 
are to be rejected because the received signal quality is 
inadequate 



ETSI 



171 



ETSI TS 102 361-4 V1.2.1 (2006-09) 



A.4 Tier III Gateways/Identifiers 



Table A.4: Gateways / Identifiers 



DIVIRID 


Alias 


Remark 


FFFECO^e 


PSTNI 


Gateway address for services to the PSTN using payload aligned timing 


FFFEC1,6 


PABXI 


Gateway address for services to the PABX using payload aligned timing 


FFFEC2,6 


LINEI 


Address for services to a Line Gateway using payload aligned timing 


FFFEC3i6 


IPI 


Address for services to an IP Gateway using payload aligned timing 


FFFEC4,6 


SUPLI 


Address used to identify an supplementary data service 


FFFEC5i6 


SDMI 


Address used to identify a short data service 


FFFEC616 


REGI 


Address used to identify a registration service 


FFFEC7,6 


MSI 


Address used to identify the totality of individual MS address space 


FFFEC816 


TGI 


Address used to identify the totality of talkgroup address space 


FFFEC9i6 


DIVERTI 


Address used to identify a call diversion cancellation 


FFFECA^e 


TSI 


Address of the TS 


FFFECB^e 


DISPATI 


Address of the system dispatcher 


FFFECC16 


STUNI 


MS Stun/Unstun Identifier 


FFFECD^e 


AUTHI 


Authentication Identifier 


FFFECE,6 


GPI 


Talkgroup Identifier 


FFFECF16 


KILLI 


MS KILL Identifier 
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Annex B (normative): 
Opcode Reference Lists 

B.1 CSBK/IVIBC/UDT Opcode List 

Table B.I : CSBK/MBC/UDT Opcode List 



OPCODE 


OPCODE2 


Description 


Alias 






Channel Grant 




48 


1 1 OOOO2 


Private Voice Ciiannei Grant 


PV_GRANT 


49 


11 0001 2 


Talkgroup Voice Ciiannei Grant 


TV_GRANT 


50 


11 001 O2 


Private Broadcast Voice Ciiannei Grant 


PBV_GRANT 


51 


11 001 12 


Private Data Ciiannei Grant 


PD_GRANT 


52 


11 01002 


Taikgroup Data Ciiannei Grant 


TD_GRANT 














IVIove 




56 


11 10002 


iVIove PDUs 


C_MOVE 














Aloha 




24 


01 IOOI2 


Aioiia PDUs for tiie random access protocoi 


C_ALOHA 














Announcements 




40 


1010002 


Announcement PDUs tiiat siiaii not demand a response. 
Announce/Witiidraw TSCC 
Specify caii Timers 
Vote now advice 
Announce iocai time 
Announce a iogicai piiysicai ciiannei reiationsiiip 


C_BCAST 


44 


1011102 


Ciear 


P_CLEAR 


45 


1011112 


Protect 


P_PROTECT 














Ahoy PDUs 




28 


01 IIOO2 


Aiioy - enquiry tiiat demands a response TSCC 


AHOY 














Acknowledgements 




32 


1000002 


Acknowiedgement response outbound TSCC 


C_ACKD 


33 


10 0001 2 


Acknowiedgement response inbound TSCC 


C_ACKU 


34 


1000102 


Acknowiedgement response outbound Payioad 


P_ACKD 


35 


1000112 


Acknowiedgement response inbound Payioad 


P_ACKU 














UDT Header 




26 


01 IOIO2 


Unified Data Transport Download Header 


C_UDTHD 


27 


01 IOII2 


Unified Data Transport Upload Header 


C_UDTHU 














Random Access Service Request 




31 


01 IIII2 


Random Access Service Request 


C_RAND 














Ackvitation 




30 


01 IIIO2 


Ackvitation PDU 


C_ACKVIT 














Maintenance PDU 




42 


1010102 


IVIaintenance 


P_MAINT 
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B.2 Short Link Control Opcode List 



Table B.2: SLCO Opcode List 



SLCO 


Description 


Alias 


001 O2 


System Parameters and slot counter 


SYS_Parm 



B.3 Appended Data Information Elements 

A UDT PDU may carry information elements. A UDT header PDU carries the source and destination addresses and a 
UDT Format information element that prescribes the format of the appended data. 

The UDT Header is the first block of a multi-block UDT. The number of blocks making up the multi-block UDT is 
specified by the AB information element. All PDUs are specified in clause 7.2. 



UDT HEADER 




7 6 


5 4 


3 2 10 


Octet OlH A 


RSVD 


FORMAT 


Octet 1 


SAP 


UDT FORMAT 


Octet 2 


TARGET ADDRESS OR 
(5ATEWAy(24) 


Octet 3 


Octet 4 


Octet 5 


SOURCE ADDRESS OR 
(5ATEWAy(24) 


Octet 6 


Octet 7 


Octet 8 


PAD NIBBLE UAB 


Octet 9B3pF 


OPCODE 



HEADER BLOCK 



Figure B.I: UDT header Block 



B.3.1 Appended Data Binary Format 



Appended data is binary coded. Up to four appended UDT blocks may be concatenated with the UDT header to form a 
multi-block UDT PDU. Up to 297 bits may be transported. For binary format transport the Pad Nibble information 
element in the UDT header is set to OOOO2. If variable length binary data is being transported, the last bit of the user 

data may identified as follows: 

• A O2 is appended to the user data and the remaining bits to fill a UDT block are set to I2. The UDT header and 
appended blocks are then transmitted. 

• The receiver may identify the end of user data by counting backwards until the first O2 is reached. That point is 
one bit past the user data. 
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APPENDED DATA UDTF=00002 




7654321 





Octet 


Binary(80) 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 



APPENDED MBC #1 



Figure B.2: Unified Data Transport Format (Binary) 1 bit to 79 bits 

One appended UDT may transport from 1 bit to 79 bits (because the last user bit must be identified by adding a O2 to the 
end of the user data). 



APPENDED DATA UDTF=00002 




7|6|5|4|3|2|l|0 


Octet 


Binary(96) 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 


Octet 10 


Octet 11 



APPENDED DATA UDTF=00002 




7|6|5|4|3|2|l|0 


Octet 


Binary(80) 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 



APPENDED MBC #2 



APPENDED MBC #1 



Figure B.3: Unified Data Transport Format (Binary) 80 bits to 175 bits 

Two appended UDTs may transport from 80 bits to (96+79) =175 bits. 



APPENDED DATA UDTF=00002 




76543210 


Octet 


Binary(96) 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 


Octet 10 


Octet 11 




APPENDED MBC #1 



APPENDED DATA UDTF=00002 




76543210 


Octet 


Biiiary(96) 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 


Octet 10 


Octet 11 




APPENDED MBC #2 



APPENDED DATA UDTF-OOOO2 




76543210 


Octet 


Biiiary(80) 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 




APPENDED MBC #3 



Figure B.4: Unified Data Transport Format (Binary) 176 bits to 366 bits 

Three appended UDTs may transport from 176 bits to (96+96+79) = 366 bits. 
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APPENDED DATA UDTF=00002 




7|6|5|4|3|2|1|0 


Octet 


Binary(96) 


Octet 1 


Octet 2 


Octets 


Octet 4 


Octet 5 


Octet 6 


Octet/ 


Octets 


Octet 9 


Octet 10 


Octet 11 




APPENDED MBC #1 



APPENDED DATA UDTF=00002 




7|6|5|4|3|2|1|0 


Octet 


Binary(96) 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 


Octet 10 


Octet 11 




APPENDED MBC #2 



APPENDED DATA UDTF=00002 




7|6|5|4|3|2|1|0 


Octet 


Binary(96) 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octets 


Octet 9 


Octet 10 


Octet 11 




APPENDED MBC #3 



APPENDED DATA UDTF=00002 




7|6|5|4|3|2|1|0 


Octet 


Binary(SO) 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octets 


Octet 9 




APPENDED MBC #4 



Figure B.5: Unified Data Transport Format (Binary) 366 bits to 462 bits 

Four appended UDTs may transport from 366 bits to (96+96+96+79) = 462 bits. 

B.3.2 Appended Data Addressing Format 

Appended data is 24 bit address coded. One appended data UDTs may be concatenated with a UDT appended data 
header to form a multi-block UDT PDU. Up to three addresses may be transported. 



APPENDED DATA UDTF=000l2 




7 1 6 


5 1 4 1 3 1 2 1 1 1 


Octet 


RSVb 


CSBK Opcocle(6) 


Octet 1 


AbbRESSl(24) 


Octet 2 


Octet 3 


Octet 4 


AbbRESS2(24) 


Octet 5 


Octet 6 


Octet 7 


AbbRESS3(24) 


Octet 8 


Octet 9 







APPENDED MBC #1 



Figure B.6: Appended data Address Format 

Unused address information elements are filled with NULL. 

B.3.3 Appended Data BCD Format 

Appended data is BCD coded. Up to four appended data UDTs may be concatenated with UDT appended data header to 
form a multi-block UDT PDU. Up to 92 BCD digits may be transported. The Pad Nibble information element in the 
UDT header specifies the number of 4 bit nibbles (1 1 1 12) that have been padded to the user digits to completely fill a 
block. 

The number of user BCD digits and the corresponding value of AB and Pad Nibble is given by table B.3. 
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Table B.3: Relationship of user BCD digits, UAB and Pad Nibble information elements 



User 
BCD 
Digits 


UAB 


Pad Nibble 


1 





19 


2 





18 


3 





17 


4 





16 


5 





15 


6 





14 


7 





13 


8 





12 


9 





11 


10 





10 


11 





9 


12 





8 


13 





7 


14 





6 


15 





5 


16 





4 


17 





3 


18 





2 


19 





1 


20 








21 




23 


22 




22 


23 




21 


24 




20 


25 




19 


26 




18 


27 




17 


28 




16 


29 




15 


30 




14 


31 




13 



User 
BCD 
Digits 


UAB 


Pad Nibble 


32 




12 


33 




11 


34 




10 


35 




9 


36 




8 


37 




7 


38 




6 


39 




5 


40 




4 


41 




3 


42 




2 


43 




1 


44 







45 


2 


23 


46 


2 


22 


47 


2 


21 


48 


2 


20 


49 


2 


19 


50 


2 


18 


51 


2 


17 


52 


2 


16 


53 


2 


15 


54 


2 


14 


55 


2 


13 


56 


2 


12 


57 


2 


11 


58 


2 


10 


59 


2 


9 


60 


2 


8 


61 


2 


7 


62 


2 


6 



User 
BCD 
Digits 


UAB 


Pad Nibble 


63 


2 


5 


64 


2 


4 


65 


2 


3 


66 


2 


2 


67 


2 


1 


68 


2 





69 


3 


23 


70 


3 


22 


71 


3 


21 


72 


3 


20 


73 


3 


19 


74 


3 


18 


75 


3 


17 


76 


3 


16 


77 


3 


15 


78 


3 


14 


79 


3 


13 


80 


3 


12 


81 


3 


11 


82 


3 


10 


83 


3 


9 


84 


3 


8 


85 


3 


7 


86 


3 


6 


87 


3 


5 


88 


3 


4 


89 


3 


3 


90 


3 


2 


91 


3 


1 


92 


3 












APPENbEb bATA UbTF=00102 




7|6|5|4 


3|2|1|0 


Octet 


Digit(4) 


Digit(4) 


Octet 1 


Digit(4) 


Digit(4) 


Octet 2 


Digit(4) 


Digit(4) 


Octets 


Digit(4) 


Digit(4) 


Octet 4 


Diqit(4) 


Diqit(4) 


Octets 


Digit(4) 


Digit(4) 


Octet 6 


Digit(4) 


Digit(4) 


Octet? 


Digit(4) 


Digit(4) 


Octets 


Digit(4) 


Digit(4) 


Octet 9 


Digit(4) 


Digit(4) 



APPENbEb MBC #1 



Figure B.7: Unified Data Transport Format (BCD) 1 digit to 20 digits 
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APPENDED DATA UDTF=00102 




7|6|5|4 


3 1 2 1 1 1 


Octet 


Digit(4) 


Digit(4) 


Octet 1 


Digit(4) 


Digit(4) 


Octet 2 


Digit(4) 


Digit(4) 


Octet 3 


Digit(4) 


Digit(4) 


Octet 4 


Digit(4) 


Digit(4) 


Octet 5 


Digit(4) 


Digit(4) 


Octet 6 


Digit(4) 


Digit(4) 


Octet 7 


Digit(4) 


Digit(4) 


Octet 8 


Digit(4) 


Digit(4) 


Octet 9 


Digit(4) 


Digit(4) 


Octet 10 


Digit(4) 


Digit(4) 


Octet 11 


Digit(4) 


Digit(4) 




APPENDED mC #1 



APPENDED DATA UDTF=00102 




7|6|5|4 


3|2| 1 |0 


Octet 


Digit(4) 


Digit(4) 


Octet 1 


Digit(4) 


Digit(4) 


Octet 2 


Digit(4) 


Digit(4) 


Octet 3 


Digit(4) 


Digit(4) 


Octet 4 


Digit(4) 


Digit(4) 


Octet 5 


Digit(4) 


Digit(4) 


Octet 6 


Digit(4) 


Digit(4) 


Octet 7 


Digit(4) 


Digit(4) 


Octet 8 


Digit(4) 


Digit(4) 


Octet 9 


Digit(4) 


Digit(4) 




APPENDED MBC #2 



Figure B.8: Unified Data Transport Format (BCD) 21 digits to 44 digits 



APPENDED DATA UDTF=00102 




7|6|5|4 


3 1 2 1 1 1 


Octet 


Digit(4) 


Digit(4) 


Octet 1 


Digit(4) 


Digit(4) 


Octet 2 


Digit(4) 


Digit(4) 


Octet 3 


Digit(4) 


Digit(4) 


Octet 4 


Digit(4) 


Digit(4) 


Octet 5 


Digit(4) 


Digit(4) 


Octet 6 


Digit(4) 


Digit(4) 


Octet 7 


Digit(4) 


Digit(4) 


Octet 8 


Digit(4) 


Digit(4) 


Octet 9 


Digit(4) 


Digit(4) 


Octet 10 


Digit(4) 


Digit(4) 


Octet 11 


Digit(4) 


Digit(4) 




APPENDED MBC #1 



APPENDED DATA UDTF=00102 




7|6|5|4 


3 1 2 1 1 1 


Octet 


Digit(4) 


Digit(4) 


Octet 1 


Digit(4) 


Digit(4) 


Octet 2 


Digit(4) 


Digit(4) 


Octet 3 


Digit(4) 


Digit(4) 


Octet 4 


Digit(4) 


Digit(4) 


Octet 5 


Digit(4) 


Digit(4) 


Octet 6 


Digit(4) 


Digit(4) 


Octet 7 


Digit(4) 


Digit(4) 


Octet 8 


Digit(4) 


Digit(4) 


Octet 9 


Digit(4) 


Digit(4) 


Octet 10 


Digit(4) 


Digit(4) 


Octet 11 


Digit(4) 


Digit(4) 




APPENDED MBC #2 



APPENDED DATA UDTF=00102 




7 1 6 1 5 1 4 


3|2| 1 |0 


Octet 


Digit(4) 


Digit(4) 


Octet 1 


Digit(4) 


Digit(4) 


Octet 2 


Digit(4) 


Digit(4) 


Octet 3 


Digit(4) 


Digit(4) 


Octet 4 


Digit(4) 


Digit(4) 


Octet 5 


Digit(4) 


Digit(4) 


Octet 6 


Digit(4) 


Digit(4) 


Octet 7 


Digit(4) 


Digit(4) 


Octet 8 


Digit(4) 


Digit(4) 


Octet 9 


Digit(4) 


Digit(4) 




APPENDED MBC #3 



Figure B.9: Unified Data Transport Format (BCD) 45 digits to 65 digits 



APPENDED DATA UDTF=00102 




7|6|5|4 


3|2|1 |0 


Octet 


Digit(4) 


Digit(4) 


Octet 1 


Digit(4) 


Digit(4) 


Octet 2 


Digit(4) 


Digit(4) 


Octet 3 


Digit(4) 


Digit(4) 


Octet 4 


Digit(4) 


Digit(4) 


Octet 5 


Digit(4) 


Digit(4) 


Octet 6 


Digit(4) 


Digit(4) 


Octet 7 


Digit(4) 


Digit(4) 


Octet 8 


Digit(4) 


Digit(4) 


Octet 9 


Digit(4) 


Digit(4) 


Octet 10 


Digit(4) 


Digit(4) 


Octet 11 


Digit(4) 


Digit(4) 




APPENDED MBC #1 



APPENDED DATA UDTF=00102 




7 1 6 1 5 1 4 


3|2|1|0 


Octet 


Digit(4) 


Digit(4) 


Octet 1 


Digit(4) 


Digit(4) 


Octet 2 


Digit(4) 


Digit(4) 


Octet 3 


Digit(4) 


Digit(4) 


Octet 4 


Digit(4) 


Digit(4) 


Octet 5 


Digit(4) 


Digit(4) 


Octet 6 


Digit(4) 


Digit(4) 


Octet 7 


Digit(4) 


Digit(4) 


Octet 8 


Digit(4) 


Digit(4) 


Octet 9 


Digit(4) 


Digit(4) 


Octet 10 


Digit(4) 


Digit(4) 


Octet 11 


Digit(4) 


Digit(4) 




APPENDED MBC #2 



APPENDED DATA UDTF=00102 




7|6|5|4 


3 1 2 1 1 1 


Octet 


Digit(4) 


DigiK4) 


Octet 1 


Digit(4) 


DigiK4) 


Octet 2 


Digit(4) 


DigiK4) 


Octet 3 


Digit(4) 


DigiK4) 


Octet 4 


Digit(4) 


DigiK4) 


Octet 5 


Digit(4) 


DigiK4) 


Octet 6 


Digit(4) 


DigiK4) 


Octet 7 


Digit(4) 


DigiK4) 


Octet 8 


Digit(4) 


DigiK4) 


Octet 9 


Digit(4) 


DigiK4) 


Octet 10 


Digit(4) 


DigiK4) 


Octet 11 


Digit(4) 


DigiK4) 




APPENDED MBC #3 



APPENDED DATA UDTF=00102 




7 1 6 1 5 1 4 


3|2|1|0 


Octet 


Digit(4) 


Digit(4) 


Octet 1 


Digit(4) 


Digit(4) 


Octet 2 


Digit(4) 


Digit(4) 


Octet 3 


Digit(4) 


Digit(4) 


Octet 4 


Digit(4) 


Digit(4) 


Octet 5 


Digit(4) 


Digit(4) 


Octet 6 


Digit(4) 


Digit(4) 


Octet 7 


Digit(4) 


Digit(4) 


Octet 8 


Digit(4) 


Digit(4) 


Octet 9 


Digit(4) 


Digit(4) 




APPENDED MBC #4 



Figure B.10: Unified Data Transport Format (BCD) 66 digits to 92 digits 

B.3.4 Appended Data ISO 7 bit character set Format 

Appended data is coded ISO 7 bit character set (ISO/IEC 646 [11]). Up to four appended data UDTs may be 
concatenated with a UDT appended data header to form a muki-block UDT PDU. Up to 52 ISO 7 bit characters may be 
transported. The Pad Nibble information element in the UDT header specifies the number of 4 bit nibbles (1 1 1 12) that 
have been padded to the 7 bit character symbols to completely fill a block. An exact fit of pad nibbles is not always 
possible but there is sufficient indication to unambiguously specify the number of text symbols. 

The number of user 7 bit character symbols, and the corresponding value of UAB and Pad Nibble is given by table B.4. 



ETSI 



178 



ETSI TS 102 361-4 V1.2.1 (2006-09) 



Table B.4: Relationship of ISO 7 bit symbols, UAB and Pad Nibble information elements 



User 7 bit 
Symbols 


UAB 


Pad Nibble 


1 





18 


2 





16 


3 





14 


4 





13 


5 





11 


6 





9 


7 





7 


8 





6 


9 





4 


10 





2 


11 








12 




23 


13 




21 


14 




19 


15 




17 


16 




16 


17 




14 


18 




12 



User 7 bit 
Symbols 


UAB 


Pad Nibble 


19 




10 


20 




9 


21 




7 


22 




5 


23 




3 


24 




2 


25 







26 


2 


22 


27 


2 


20 


28 


2 


19 


29 


2 


17 


30 


2 


15 


31 


2 


13 


32 


2 


12 


33 


2 


10 


34 


2 


8 


35 


2 


6 


36 


2 


5 



User 7 bit 
Symbols 


UAB 


Pad Nibble 


37 


2 


3 


38 


2 


1 


39 


3 


23 


40 


3 


22 


41 


3 


20 


42 


3 


18 


43 


3 


16 


44 


3 


15 


45 


3 


13 


46 


3 


11 


47 


3 


9 


48 


3 


8 


49 


3 


6 


50 


3 


4 


51 


3 


2 


52 


3 


1 















APPENDED DATA UDTF=001l2 




7|6|5|4|3|2|1 





Oc-tetO 


Digit(7) 




Octet 1 


Digit(7) 1 


Octet 2 


Digit(7) 1 


Octets 


Digit(7) 1 DigiK7) 


Octet 4 


1 Digit(7)- 


Octets 


1 DigiK7) 


Octet 6 


1 DigiK7) 


Octet? 


Digit(7) 1 


Octets 


Digit(7) 


— 


Octet 9 


Digit(7) 1 1 


1 1 



APPENDED MBC #1 



Figure B.11 : Unified Data Transport Format (ISO 7 bit) 1 text symbol to 11 text symbols 



APPENDED DATA UDTF=001l2 




7|6|5|4|3|2| 1 





Octet 


Digit(7) 




Octet 1 


Digit(7) 1 


Octet 2 


Digit(7) 1 


Octet 3 


Digit(7) 1 Digit(7) 


Octet 4 


1 Digit(7)- 


Octet 5 


1 C)igit(7) 


Octet 6 


1 C)igit(7) 


Octet 7 


Digit(7) 1 


Octet 8 


Digit(7) 1 -- 


Octet 9 


Digit(7) 1 


Octet 10 


Digit(7) 1 Digit(7) 


Octet 11 


1 Digit(7)— 




APPENDED MBC #1 



APPENDED DATA UDTF=001l2 




7 1 6 


5|4|3|2| 1 |0 


Octet 




Digit(7) 


Octet 1 


1 C)igit(7) 


Octet 2 


Digit(7) \ 


Octet 3 


Digit(7) 1 — - 


Octet 4 


Digit(7) 1 


Octet 5 


Digit(7) | Digit(7) 


Octet 6 


1 Digit(7)- 


Octet 7 


1 C)igit(7) 


Octet 8 


Digit(7) 


Octet 9 


Digit(7) 1 1 




APPENDED MBC #2 



Figure B.I 2: Unified Data Transport Format (ISO 7 bit) 12 text symbols to 25 text symbols 
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APPENDED DATA UDTF=001l2 




7|6|5|4|3|2| 1 





Octet 


Digit(7) 




Octet 1 


Digit(7) 1 


Octet 2 


Digit(7) 1 


Octets 


Digit(7) 1 Digit(7) 


Octet 4 


1 Digit(7)- 


Octets 


1 (^igi1(7) 


Octet 6 


1 (^igiK7) 


Octet? 


(^igit(7) \ 


Octets 


Digit(7) 1 -- 


Octet 9 


Digit(7) 1 


Octet 10 


Digit(7) 1 Digit(7) 


Octet 11 


1 Digit(7)- 




APPENDED MBC #1 



APPENDED DATA UDTF=001l2 




7 1 6 


5 1 4 1 3 1 2 1 1 1 


Octet 




Digit(7) 


Octet 1 


1 (^igi1(7) 


Octet 2 


(^igit(7) L 


Octets 


Digit(7) 1 -- 


Octet 4 


Digit(7) 1 


Octets 


Digit(7) 1 Digit(7) 


Octet 6 


1 Digit(7)- 


Octet 7 


1 (^igi1(7) 


Octets 


1 (^igiK7) 


Octet 9 


Digit(7) 1 


Octet 10 


Digit(7) 1 


Octet 11 


Digit(7) 




APPENDED MBC #2 



APPENDED DATA UDTF=001l2 




7|6|S|4 


3|2| 1 |0 


Octet 


Digit(7) 


Digit(7) 


Octet 1 


1 Digit(7)- 


Octet 2 


1 (^igi1(7) 


Octets 


1 (^igiK7) 


Octet 4 


Digit(7) 1 


Octets 


Digit(7) 1 -- 


Octet 6 


Digit(7) 1 


Octet 7 


Digit(7) 1 Digit(7) 


Octets 




Digit(7)- 


Octet 9 


h 


1 |l|l|l |l 



APPENDED MBC #3 



Figure B.13: Unified Data Transport Format (ISO 7 bit) 26 text symbols to 38 text symbols 



APPENDED DATA UDTF=001l2 




7|6|5|4|3|2|1 





Octet 


Digit(7) 




Octet 1 


Digit(7) 1 


Octet 2 


Digit(7) 


Octet 3 


Digit(7) 1 Digit(7) 


Octet 4 


Digit(7)— 


Octet 5 


1 Digit(7) 


Octet 6 


1 bigit(7) 


Octet 7 


Digit(7) 1 


Octet 8 


Digit(7) 1 -- 


Octet 9 


Digit(7) 1 


Octet 10 


Digit(7) 1 Digit(7) 


Octet 11 


1 Digit(7)- 




APPENDED MBC #1 



APPENDED DATA UDTF=001l2 




7|6 


5 1 4 1 3 1 2 1 1 1 


Octet 




Digit(7) 


Octet 1 


1 Digit(7) 


Octet 2 


bigit(7) L 


Octet 3 


Digit(7) 1 -- 


Octet 4 


Digit(7) 1 


Octet 5 


Digit(7) 1 Digit(7) 


Octet 6 


1 Digit(7)— 


Octet 7 


1 bigit(7) 


Octet 8 


1 bigit(7) 


Octet 9 


Digit(7) 1 


Octet 10 


Digit(7) 1 


Octet 11 


Digit(7) 1 




APPENDED MBC #2 



APPENDED DATA UDTF=001l2 




7|6|5|4 


3 1 2 1 1 1 


Octet 


Digit(7) 


Digit(7) 


Octet 1 


1 Digit(7)— 


Octet 2 


1 bigit(7) 


Octet 3 


1 Digit(7) 


Octet 4 


Digit(7) 1 


Octet 5 


Digit(7) 1 


Octet 6 


Digit(7) 1 


Octet 7 


Digit(7) Digit(7) 


Octet 8 


1 Digit(7)- 


Octet 9 


1 bigit(7) 


Octet 10 


1 bigit(7) 


Octet 11 


Digit(7) 1 




APPENDED MBC #3 



APPENDED DATA UDTF=001l2 




7|6|5|4|3|2|1|0 


Octet 


Digit(7) 1 — - 


Octet 1 


Digit(7) 1 


Octet 2 


Digit(7) Digit(7) 


Octet 3 


1 Digit(7)- 


Octet 4 


1 bigit(7) 


Octet 5 


1 Digit(7) 


Octet 6 


Digit(7) 1 


Octet 7 


Digit(7) 1 


Octet 8 


Digit(7) 


Octet 9 


Digit(7) 1111 




APPENDED MBC #4 



Figure B.14: Unified Data Transport Format (ISO 7 bit) 39 text symbols to 52 text symbols 

B.3.5 Appended Data ISO 8 bit Character Format 

Appended data is coded ISO 8 bit character format (ISO/IEC 8859 [12]). Up to four appended data UDTs may be 
concatenated with UDT appended data header to form a multi-block UDT PDU. Up to 46 ISO 8 bit characters may be 
transported. The Pad Nibble information element in the UDT header specifies the number of 4 bit nibbles (1 1 1 12) that 
have been padded to the Character symbols to completely fill a block. 

The number of user 8 bit characters, and the corresponding value of UAB and Pad Nibble is given by table B.5. 
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Table B.5: Relationship of 8 bit character symbols, UAB and Pad Nibble information elements 



User 
Character 
Symbols 


UAB 


Pad Nibble 


1 





18 


2 





16 


3 





14 


4 





12 


5 





10 


6 





8 


7 





6 


8 





4 


9 





2 


10 








11 




22 


12 




20 


13 




18 


14 




16 


15 




14 


16 




12 



User 
Character 
Symbols 


UAB 


Pad Nibble 


17 




10 


18 




8 


19 




6 


20 




4 


21 




2 


22 







23 


2 


22 


24 


2 


20 


25 


2 


18 


26 


2 


16 


27 


2 


14 


28 


2 


12 


29 


2 


10 


30 


2 


8 


31 


2 


6 


32 


2 


4 



User 
Character 
Symbols 


UAB 


Pad Nibble 


33 


2 


2 


34 


2 





35 


3 


22 


36 


3 


20 


37 


3 


18 


38 


3 


16 


39 


3 


14 


40 


3 


12 


41 


3 


10 


42 


3 


8 


43 


3 


6 


44 


3 


4 


45 


3 


2 


46 


3 


















APPEN bEb bATA UbTF=01002 



Octet 



Octet 1 



Octet 2 



Octet 3 



Octet 4 



Octet 5 



Octet 6 



Octet 7 



Octet 8 



Octet 9 



76543210 



Digit(8) 



Digit(8) 



Digit(8) 



Digit(8) 



Digit(8) 



Digit(8) 



Digit(8) 



Digit(8) 



Digit(8) 



Digit(8) 



APPENbEb MBC #1 



Figure B.15: Unified Data Transport Format (8 bit character) 1 character symbol 

to 10 character symbols 



APPENDED DATA UDTF=01002 




7|6|5|4|3|2|l 





Octet 


Digit(8) 


Octet 1 


Digit(8) 


Octet 2 


Digit(8) 


Octets 


Digit(8) 


Octet 4 


Digit(8) 


Octets 


Digit(8) 


Octet 6 


Digit(8) 


Octet 7 


Digit(8) 


Octets 


Digit(8) 


Octet 9 


Digit(8) 


Octet 10 


Digit(8) 


Octet 11 


Digit(8) 




APPENDED MBC #1 



APPENDED DATA UDTF=01002 




7|6|5|4|3|2|l 





Octet 


Digit(8) 


Octet 1 


Digit(8) 


Octet 2 


Digit(8) 


Octets 


Digit(8) 


Octet 4 


Digit(8) 


Octets 


Digit(8) 


Octet 6 


Digit(8) 


Octet 7 


Digit(8) 


Octet 8 


Digit(8) 


Octet 9 


Digit(8) 




APPENDED MBC #2 



Figure B.I 6: Unified Data Transport Format (8 bit character) 11 character symbols 

to 22 character symbols 
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APPENDED DATA UDTF=01002 




7|6|5|4|3|2|1|0 


Octet 


Digit(8) 


Octet 1 


Digit(8) 


Octet 2 


Digit(8) 


Octet 3 


Digit(8) 


Octet 4 


Digit(8) 


Octet 5 


Digit(8) 


Octet 6 


Digit(8) 


Octet 7 


Digit(8) 


Octet 8 


Digit(8) 


Octet 9 


Digit(8) 


Octet 10 


Digit(8) 


Octet 11 


Digit(8) 




APPENDED MBC #1 



APPENDED DATA UDTF=01002 




7|6|5|4|3|2|1|0 


Octet 


Digit(8) 


Octet 1 


Digit(8) 


Octet 2 


Digit(8) 


Octet 3 


Digit(8) 


Octet 4 


Digit(8) 


Octet 5 


Digit(8) 


Octet 6 


Digit(8) 


Octet? 


Digit(8) 


Octet 8 


Digit(8) 


Octet 9 


Digit(8) 


Octet 10 


Digit(8) 


Octet 11 


Digit(8) 




APPENDED MBC #2 



APPENDED DATA UDTF=01002 




7|6|5|4|3|2|1|0 


Octet 


Digit(8) 


Octet 1 


Digit(8) 


Octet 2 


Digit(8) 


Octet 3 


Digit(8) 


Octet 4 


Digit(8) 


Octet 5 


Digit(8) 


Octet 6 


Digit(8) 


Octet 7 


Digit(8) 


Octet 8 


Digit(8) 


Octet 9 


Digit(8) 




APPENDED MBC #3 



Figure B.I 7: Unified Data Transport Format (8 bit character) 23 character symbols 

to 34 character symbols 



APPENDED DATA UDTF=01002 




7|6|5|4|3|2|l|0 


Octet 


Digit(8) 


Octet 1 


Digit(8) 


Octet 2 


Digit(8) 


Octet 3 


Digit(8) 


Octet 4 


Digit(8) 


Octet 5 


Digit(8) 


Octet 6 


Digit(8) 


Octet 7 


Digit(8) 


Octet 8 


Digit(8) 


Octet 9 


Digit(8) 


Octet 10 


Digit(8) 


Octet 11 


Digit(8) 




APPENDED MBC #1 



APPENDED DATA UDTF=01002 




7|6|5|4|3|2|l|0 


Oc-tetO 


Digit(8) 


Octet 1 


Digit(8) 


Oc-tet2 


Digit(8) 


Oc-tet3 


Digit(8) 


Oc-tet4 


Digit(8) 


Oc-tet5 


Digit(8) 


Oc-tet6 


Digit(8) 


Oc-tet7 


Digit(8) 


Oc-tet8 


Digit(8) 


Oc-tet9 


Digit(8) 


Oc-tet 10 


Digit(8) 


Octet 11 


Digit(8) 




APPENDED MBC #2 



APPENDED DATA UDTF=01002 




7|6|5|4|3|2|l|0 


Octet 


Digit(8) 


Octet 1 


Digit(8) 


Octet 2 


Digit(8) 


Octet 3 


Digit(8) 


Octet 4 


Digit(8) 


Octet 5 


Digit(8) 


Octet 6 


Digit(8) 


Octet 7 


Digit(8) 


Octet 8 


Digit(8) 


Octet 9 


Digit(8) 


Oc-tet 10 


Digit(8) 


Octet 11 


Digit(8) 




APPENDED MBC #3 



APPENDED DATA UDTF=01002 




7|6 |5|4|3 |2| 1 |0 


Oc-tet 


Digit(8) 


Octet 1 


Digit(8) 


Oc-tet 2 


Digit(8) 


Oc-tet 3 


Digit(8) 


Oc-tet 4 


Digit(8) 


Oc-tet 5 


Digit(8) 


Oc-tet 6 


Digit(8) 


Oc-tet 7 


Digit(8) 


Oc-tet 8 


Digit(8) 


Oc-tet 9 


Digit(8) 




APPENDED MBC #4 



Figure B.18: Unified Data Transport Format (8 bit character) 35 character symbols 

to 46 character symbols 

B.3.6 Appended Data NMEA (lEC 61 1 62-1 ) format 

Appended data is with essential data elements for NMEA formatted (lEC 61162-1 [8]) coordinates. Up to two appended 
data UDTs may be concatenated with a UDT appended data header to form a multi-block UDT PDU. The information 
elements are described in table B.6. 



APPENDED DATA UDTF=010l2 




7 


6 


5 


4 


3|2|1|0 


Octet 


C 


NS 


EW 


Q 


SPEED(7)— 


Octet 1 


- 


NDEe(7)— 


Octet 2 


1 NMIN(6) 


Octet 3 


NMINF(14)— 


Octet 4 








... 
1 


Octet 5 


— EDEe(8) 1 -- 


Octet 6 


-EMINmm(6) | 


Octet 7 


— EMINF(14) — 


Octet 8 


1 SPARE(6) 


Octet 9 


SPARE(8) 




APPENDED MBC #1 



Figure B.19: Appended Data Short NMEA format 
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APPENDED DATA UDTF=010l2 




^ 


6 


5 


4 


3 1 2 1 1 1 


Octet 


c 


NS 


EW 


Q 


SPEED(7)— 


Octet 1 


- 


NDEe(7)— 


Octet 2 


1 NMIN(6) 


Octet 3 


NMINF(14)— 


Octet 4 










Octet 5 


— EDEe(8) ~ 


Octet 6 


--EMINmm(6) | 


Octet 7 


— -EMINF(14)— - 


Octet 8 


1 UTChh(5) 1 - 


Octet 9 


UTCmm(6) |UTCss(6)- 


Octet 10 


1 SPARE(5) 


Octet 11 


SPARE(8) 




APPENDED MBC #1 



APPENDED DATA UDTF=010l2 




7|6|5|4|3 


2 1 1 1 


Octet 


UTChh(5) 


__. 


Octet 1 


UTCmm(6)| UTCss(6)— 


Octet 2 


:J 




Octet 3 






Octet 4 


SPARE(63) 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 







APPENDED MBC #2 



Figure B.20: Appended Data Long NMEA format 
Table B.6: Appended Data NMEA Elements 



Alias 


Length 


Value 


Description 


C 


1 





Data is not encrypted 


1 


Data is encrypted 


NS 


1 





Latitude Direction - South 


1 


Latitude Direction - North 


EW 


1 





Longitude Direction - West 


1 


Longitude Direction - East 


Q 


1 





GPS Quality Indicator - No fix 


1 


GPS Quality Indicator - Fix Valid 


SPEED 


7 




Speed in knots (0-126) 


NDEG 


7 




Latitude Degrees (00-89) 


NMINmm 


6 




Latitude Minutes (00-59) 


NMINF 


14 




Latitude Fractions of minutes (0000-9999) 


EDEG 


8 




Longitude Degrees (000-179) 


EMINmm 


6 




Longitude Minutes (00-59) 


EMINF 


14 




Longitude Fractions of minutes (0000-9999) 


RSVD 


6 






UTChh 


5 




UTC time hours (00-23) 


UTCmm 


6 




UTC time minutes (00-59) 


UTCss 


6 




UTC time seconds (00-59) 



B.3.7 UDTDMR IP format 

The UDT IP format is shown in figures B.21 and B.22. 



APPENDED DATA UDTF =01102 




7 


6|5|4|3|2| 1 |0 


Oc-tetO 


IPV4 ADDRESS(32) 


Octet 1 


OclBt2 


OclBt3 


OclBt4 


RSVD(48) 


OclBt5 


OclBt6 


OclBt7 


OclBt8 


OclBt9 



APPENDED MBC #1 



Figure B.21 : Appended Data IPV4 format 
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APPENDED DATA UDTF=01102 




7|6|5|4|3|2|1|0 


Octet 


IPV6 ADDRESS(96) — 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octets 


Octet 9 


Octet 10 


Octet 11 




APPENDED MBC #1 



APPENDED DATA UDTF=01102 




7|6|5|4|3|2|1|0 


Octet 


IPV6 ADDRESS(32) — 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


RSVD(48) 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 




APPENDED MBC #2 



Figure B.22: Appended Data IPV6 format 



B.3.8 Appended Data Unicode 1 6 bit Character Format 

Appended data is coded Unicode (lEC 61162-1 [8]) 16 bit character format. Up to four appended data UDTs may be 
concatenated with UDT appended data header to form a multi-block UDT PDU. Up to 23 Unicode characters may be 
transported. The Pad Nibble information element in the UDT header specifies the number of 4 bit nibbles (1 1 1 12) that 
have been padded to the Unicode Characters to completely fill a block. 

The number of user ISO 7 bit symbols, and the corresponding value of UAB and Pad Nibble is given by table B.7. 

Table B.7: Relationship of 16 bit UnicodeCharacter symbols, 
UAB and Pad Nibble information elements 



User 
Character 
Symbols 


UAB 


Pad Nibble 


1 





16 


2 





12 


3 





8 


4 





4 


5 








6 


1 


20 


7 


1 


16 


8 


1 


12 



User 
Character 
Symbols 


UAB 


Pad Nibble 


9 


1 


8 


10 


1 


4 


11 


1 





12 


2 


20 


13 


2 


16 


14 


2 


12 


15 


2 


8 


16 


2 


4 



User 
Character 
Symbols 


UAB 


Pad Nibble 


17 


2 





18 


3 


20 


19 


3 


16 


20 


3 


12 


21 


3 


8 


22 


3 


4 


23 


3 












APPENDED DATA UDTF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encocling(16) 


Octet 1 


Octet 2 


Character Encocling(16) 


Octets 


Octet 4 


Character Encocling(16) 


Octets 


Octet 6 


Character Encocling(16) 


Octet/ 


Octets 


Character Encocling(16) 


Octet 9 



APPENDED MBC #1 



Figure B.23: Unified Data Transport Format (16 bit character) 1 character symbol 

to 5 character symbols 
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APPENtJEt) DATA Ut)TF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encocling(16) 


Octet 1 


Octet 2 


Character Encocling(16) 


Octet 3 


Octet 4 


Character Encocling(16) 


Octet 5 


Octet 6 


Character Encocling(16) 


Octet 7 


Octet 8 


Character Encocling(16) 


Octet 9 


Octet 10 


Character Encocling(16) 


Octet 11 




APPENDED MBC #1 



APPENDED DATA UDTF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encocling(16) 


Octet 1 


Octet 2 


Character Encocling(16) 


Octet 3 


Octet 4 


Character Encocling(16) 


Octet 5 


Octet 6 


Character Encocling(16) 


Octet 7 


Octet 8 


Character Encocling(16) 


Octet 9 




APPENDED MBC #2 



Figure B.24: Unified Data Transport Format (16 bit character) 6 cliaracter symbols 

to 11 cliaracter symbols 



APPENDED DATA UDTF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encocling(16) 


Octet 1 


Octet 2 


Character Encocling(16) 


Octet 3 


Octet 4 


Character Encocling(16) 


Octet 5 


Octet 6 


Character Encocling(16) 


Octet 7 


Octet 8 


Character Encocling(16) 


Octet 9 


Octet 10 


Character Encocling(16) 


Octet 11 




APPENDED MBC #1 



APPENDED DATA UDTF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encocling(16) 


Octet 1 


Octet 2 


Character Encocling(16) 


Octet 3 


Octet 4 


Character Encocling(16) 


Octet 5 


Octet 6 


Character Encocling(16) 


Octet 7 


Octet 8 


Character Encocling(16) 


Octet 9 


Octet 10 


Character Encocling(16) 


Octet 11 




APPENDED MBC #2 



APPENDED DATA UDTF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encocling(16) 


Octet 1 


Octet 2 


Character Encocling(16) 


Octet 3 


Octet 4 


Character Encocling(16) 


Octet 5 


Octet 6 


Character Encocling(16) 


Octet 7 


Octet 8 


Character Encocling(16) 


Octet 9 




APPENDED MBC #3 



Figure B.25: Unified Data Transport Format (8 bit character) 12 character symbols 

to 17 character symbols 



APPENDED DATA UDTF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encoding(16) 


Octet 1 


Octet 2 


Character Encoding(16) 


Octet 3 


Octet 4 


Character Encoding(16) 


Octet 5 


Octet 6 


Character Encoding(16) 


Octet 7 


Octet 8 


Character Encoding(16) 


Octet 9 


Octet 10 


Character Encoding(16) 


Octet 11 




APPENDED MBC #1 



APPENDED DATA UDTF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encoding(16) 


Octet 1 


Octet 2 


Character Encoding(16) 


Octet 3 


Octet 4 


Character Encoding(16) 


Octet 5 


Octet 6 


Character Encoding(16) 


Octet 7 


Octet 8 


Character Encoding(16) 


Octet 9 


Octet 10 


Character Encoding(16) 


Octet 11 




APPENDED MBC #2 



APPENDED DATA UDTF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encoding(16) 


Octet 1 


Octet 2 


Character Encoding(16) 


Octet 3 


Octet 4 


Character Encoding(16) 


Octet 5 


Octet 6 


Character Encoding(16) 


Octet 7 


Octet 8 


Character Encoding(16) 


Octet 9 


Octet 10 


Character Encoding(16) 


Octet 11 




APPENDED MBC #3 



APPENDED DATA UDTF=011l2 




7|6|5|4|3|2|1|0 


Octet 


Character Encoding(16) 


Octet 1 


Octet 2 


Character Encoding(16) 


Octet 3 


Octet 4 


Character Encoding(16) 


Octet 5 


Octet 6 


Character Encoding(16) 


Octet 7 


Octet 8 


Character Encoding(16) 


Octet 9 




APPENDED MBC #4 



Figure B.26: Unified Data Transport Format (8 bit character) 18 character symbols 

to 23 character symbols 
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Annex C (informative): 
Physical Channel Plan 

C.1 Transmission and Reception 

C.1.1 RF carriers 

C.1 .1.1 Nominal carriers frequencies 

The nominal carrier frequencies for DMR may be allocated in any of the frequency bands in the range 50 MHz to 
999 MHz. Upper layers of the protocol stack define a single logical channel number that equates to a transmitter and 
receiver frequencies in the range 1 to 4 094. Since the DMR Standard supports re-assigning of existing analogue 
channels, flexibility may be provided where prescribed channel plans are suitable. 

DMR may therefore support: 

• a number of fixed channel plans where the MS transmit frequency, the split between transmit and receive, the 
channel separation and if the receiver is high or low relative to the transmitter; 

• a flexible channel plan whereby each logical channel may represent a transmitter and receiver frequency pair; 

• a broadcast PDU that enables the TSCC to announce a logical / physical transmitter and receiver relationship; 

• an extended channel grant PDU that specifies the physical transmitter and receiver frequencies. 

The higher DMR layers only have the logical CHAN SDU to define the physical frequencies. The additional parameters 
(type of channel plan, Tx/Rx separation, etc.) exist in the physical layer only and are programmed during 
personalization or manufacture of the equipment. It must be remembered that a National Administration may mandate 
certain limitations on particular frequencies (such as transmitter power). 

C.1 .1 .2 Fixed Channel Plan 

The nominal MS Tx frequency fjyj^ j^ corresponds to its logical carrier number, CHAN, which is defined as: 
^MS Tx " ^^ transmit frequency (MHz) 

^base " ^^^ lowest frequency in a particular band relating to logical CHAN=1 (MHz) 
^separation " ^^^ frequency separation between two adjacent channels (kHz) 

^duplexsplit - The difference between MS Tx and MS Rx [for clarity MS Tx minus MS Rx] (±MHz) 
fMS_Tx = ^base + ((CHAN-1) X (f separation/ 1 OOo)) ^^^ 
^MS.Rx = ^MS.Tx - ^duplexsplit ^^^ 
^duplexsplit - ^ MHz to 50 MHz in 2,5 kHz steps 
^separation- Definition 
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Table C.1 : Frequency Separation 



SDU Code (SEP) 


Separation (l<Hz) 


OOOO2 


5 


0001 2 


6,25 


001 O2 


10 


00112 


12,5 


01002 


15 


01012 


20 


01102 


25 


01112 


30 


1XXX2 


reserved 



fgplj^ - The difference between MS Tx and MS Rx [for clarity MS Tx minus MS Rx] (±MHz) 

Table C.2: Frequency Split high/low 



SDU Code (TXRX SPLIT) 




O2 


MS Tx is high of IVIS Rx 


I2 


IVIS Tx is low of IVIS Rx 



fduplexsplit - Definition 



Table C.3: Frequency Split 



SDU Code (DUPLEX SPLIT) 


Duplex Split (kHz) 


000 0000 0000 OOOO2 





000 0000 0000 0001 2 


2,5 






000 01 1 1 001 1 OOOO2 


4 600 (4,6 MHz) 






0001100100000002 


8 000 (8 MHz) 






000 1111 1010000O2 


10 000 (10 MHz) 






10001100101 OOOO2 


45 000 (45 MHz) 



^base " ^^^^ Definition 



Table 0.4: Band Definition 



SDU Code (BAND) 


fbaseMHz 


000 0011 2 


30 


00001002 


40 


00001012 


50 


00001102 


60 


00001112 


70 






01011002 


450 






101 OOOO2 


800 


11001002 


1 000 
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chan - Logical Channel Numbers 



Table C.5: Logical Channel Numbers 



Channel Number 


SDU Code (CHAN) 


Colour Code (see note) 


1 


0000 0000 0001 2 


Value 








4 094 


1111 1111 11102 


Value 


NOTE: The default colour code =00002- 



C.1 .1 .3 Flexible Channel Plan 

Each logical channel number has the transmitter and receiver frequency defined. 

Table C.6: Flexible Channel Plan 



Channel Number 


SDU Code (CHAN) 


Transmitter 
Frequency 


Receiver 
Frequency 


Colour Code 
(see note) 


1 


0000 0000 0001 2 






Value 












4 094 


1111 1111 11102 






Value 


NOTE: The default colour code =00002- 



c.1 .1 .4 Determination of Transmitter and Receiver frequency from 
CdefParms 

The MS absolute transmitter and receiver frequency is defined in 125 Hz steps as shown in table C.7. 

Table 0.7: Absolute Transmitter and Receiver SDUs 



ALIAS 


SDU Code 


Transmitter/Receiver Frequency 


TXMHz 
RXMHz 


000 0011 001 O2 


50Mhz 


111 110011112 


999 MHz 


TXKHz 
RXKHz 


0000 0000 OOOO2 


OHz 


0000 0000 0001 2 


+125 Hz 


0000 0000 001 O2 


+250 Hz 


1 1111 0011 IIII2 


+999 875 Hz 



The absolute transmitter frequency (MHz) = TXMHz + (TXKHz x 125)/1 000. 
The absolute receiver frequency (MHz) = RXMHz + (RXKHz x 125)/1 000. 
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Annex D (informative): 

Control Channel Hunting Procedures 

D.1 Introduction 

In order to locate a valid TSCC, the MS hunts through a list candidate physical channels until an appropriate TSCC is 
selected and confirmed. This TSCC hunting may involve a variety of hunting sequences depending on the 
circumstances of the hunt. This annex shows a framework for MS hunting strategy. 

Since two logical TDMA channels occupy one physical channel, the MS can appraise both logical channels 
concurrently when sampling a physical channel. The MS may use information from the CACH or PDUs that contain a 
C_SYScode information element to use for verification tests specified in clause 6.3.2.2.1. 

The Control Channel Hunting Procedure stages are: 

a) The "resuming a TSCC hunt channel" allows an MS, after a period of activity on a payload physical channel, 
to resume the TSCC on which it was last confirmed prior to the payload Channel Grant PDU. 

b) The "commanded TSCC hunt channel" is employed when a MS is directed on the TSCC to a particular TSCC 
(from a C_MOVE or P_CLEAR PDU) or seeks to regain a TSCC after a period of inactivity on the selected 
network (due to being switched off or a user-initiated change of selected network when details of the last 
confirmed TSCC number have been stored by the MS in non- volatile storage). 

"Short Hunt Sequence": A hunting sequence, which samples all physical channel numbers likely to be employed as 
TSCCs by the selected network. A list of Nmax_Ch likely logical candidate physical channel numbers is held in MS 
fixed non- volatile storage for the selected network. The MS should have the storage for up to 64 values of the logical 
physical channel number information element defining the extent of the "short hunt sequence". Unused storage 
locations are marked such that the MS may ignore them. Particular Physical channel numbers may be stored in the list 
numerous times to provide a bias to that particular TSCC. 

c) "Comprehensive Hunt Sequence". A hunting sequence, that samples all possible physical channel numbers in 
use by the network. This hunting sequence provides a contingency to allow TSCCs to be acquired even when 
physical channel numbers not normally employed for this purpose are in use. The "comprehensive hunt 
sequence" may be temporarily suspended to sample likely physical channels or repeat a "short hunt sequence". 
The lowest Low_Comp_Ch and highest High_Comp_Ch is held in the MS fixed non-volatile storage. 

NOTE 1: The "Comprehensive Hunt Sequence" may be suppressed by network personalization. 

When carrying out a "resuming a TSCC hunt channel" or "commanded TSCC hunt channel" the hunting procedure is 
considered complete when the MS has tuned directly to the physical channel and has carried out the appropriate 
verification and confirmation procedures specified in clause 6.3. 
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Figure D.1: Physical Channel Hunting 

Figure D.l shows a possible implementation of the "Short Hunt Sequence" and "Comprehensive Hunt" Sequence. If the 
MS needs to search for an appropriate TSCC, this process searches the most likely physical channel candidates first. 
This example of a possible implementation carries out the short hunt twice, the first loop being exercised looking for a 
TSCC whose signal strength exceeds a defined value (L_SigShort). 

A hunting sequence may be considered complete when either: 

a) a physical channel is found that satisfies the TSCC verification and confirmation tests specified in clause 6.3. 
(The hunting procedure was successful); 

b) all physical channel numbers within the scope of the hunting sequence have been tested without a physical 
channel being found which satisfies the TSCC confirmation tests specified in clause 6.3 (the hunting sequence 
failed). 

The MS carries out the hunting procedure in the order described in this clause. If a hunting sequence is unsuccessfully 
completed, then the MS starts the next hunting sequence. The final hunting sequence is the "comprehensive hunt 
sequence". If this hunting sequence cannot be completed, the MS stays in this hunting sequence until a TSCC is 
confirmed. However, the foregoing provisions of this clause may be relaxed in the following circumstances: 

• the "comprehensive hunt sequence" may be suppressed by MS personalization for a network; 

• a MS in a "comprehensive hunt sequence" may elect to perform complete hunting sequences of any other type, 
returning to the "comprehensive hunt sequence" in the event of failure to confirm an appropriate TSCC; 

• a MS may elect to sample any physical channel that may satisfy the TSCC verification and confirmation tests 
specified in clause 6.3. 

Where a hunting stage involves more than one physical channel the order in which physical channels are sampled is not 
specified. However, in order to guard against bias towards certain physical channels, MSs should ensure randomness in 
the order in which physical channels are sampled by one of the following: 

• hunting physical channel numbers sequentially (e.g. from lowest to highest number) but beginning the hunting 
stage at a random position in the sequence of physical channel numbers; 

• hunting physical channel numbers in a random fashion. 
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The procedures defined in the present document are intended to provide a comprehensive range of methods that may be 
used as a basis for the design of MSs. 

NOTE 2: The specified mechanism is a framework for MSs. The use of additional or differing procedures is not 
prohibited provided that they satisfy the verification and confirmation procedures defined in the present 
document. 

EXAMPLE: A MS locating a physical channel which satisfies the TSCC confirmation tests specified in 

clause 6.3 may continue the hunt in anticipation that an alternative TSCC may be found with a 
higher received signal quality or level. Also, MSs need not limit the hunting procedures to the 
receiver sensitivity threshold levels specified and may conduct additional hunts at other levels. 



D.1 .1 Resuming a TSCC hunt channel 



When "resuming a TSCC hunt channel" the MS retunes to the logical physical channel number of the TSCC on which it 
was last confirmed. The MS should be capable of receiving on the TSCC outbound channel, which it is resuming within 
two TDM A-frames of the following instants: 

a) the end of any P_CLEAR PDU, which requires the MS to cease activity on the payload channel to which it is 
currently tuned; 

b) the end of the last payload disconnect PDU P_MAINT (Maint_Kind=DISCON) sent by the MS on a payload 
channel; 

c) the end of any call authorization check PDU (P_AUTH) received on a payload channel where the MS address 
information element in the P_AUTH PDU doe NOT match one of the addresses from the Channel Grant PDU 
that directed the MS to the payload channel; 

d) the operation of the any user initiated "call end request" by the user during a talkgroup call when the MS was 
not the call originator of the call. 

Before confirming the TSCC the MS should verify any C_SYScode received on the channel in accordance with the 
procedures of clause 6.3.2.2.1. In the event of the C_SYScode fails the verification procedures, the hunting sequence is 
considered unsuccessfully completed and the MS enters the "short hunt sequence". 

D.1 .2 Commanded TSCC hunt channel 

D.1 .2.1 Conditions to enter a Commanded TSCC hunt 

A "single channel hunt" applies when the MS is directed to a TSCC other than the one on which it was last confirmed, 
or when it is switched on whilst still retaining valid network information from previous activity on the selected network, 
or the user initiates a change of selected network and the MS still retains valid information of previous activity on the 
new selected network. The MS should be able to receive the nominated physical channel within 3 TDMA slots of the 
following instants: 

a) the end of any valid C_MOVE PDU that is applicable to the MS; 

b) the MS being switched on, provided that the unit holds a valid record of the channel number on which the MS 
was most recently confirmed; 

c) a change of selected network being initiated by the user, provided that the MS holds a valid record of the 
channel number on which the MS was most recently confirmed on the new selected network. 



ETSI 



1 91 ETSI TS 1 02 361 -4 VI .2.1 (2006-09) 

D.1 .2.2 Nominated Channel for the Single Channel Hunt 

The nominated channel is: 

a) the logical physical channel number indicated in the CONT information element of the P_CLEAR PDU; or 

b) the channel number indicated in the CONT information element the C_MOVE PDU; or 

c) the channel number held in the MSs read/write storage as the TSCC on which the unit was most recently 
confirmed on the selected network. 

The MS shall not make any transmissions on a TSCC until it has confirmed the channel in accordance with the 
procedure specified in clause 6.3. In the event of a failure of the TSCC to meet the channel confirmation criteria the 
hunting sequence is considered unsuccessfully completed. Upon unsuccessful completion of the "commanded TSCC 
hunt channel" the MS enters the "short hunt sequence". 



D.1 .2.3 Short Hunt Sequence 



A "Short Hunt Sequence" samples all physical channels most likely to be employed as TSCCs by the selected network. 
There are many strategies that may be employed but all shall search from a shortlist of candidates as follows: 

a) A list of likely physical channels shall be specified by an external agency stored in MS fixed non- volatile 
storage. 

b) The MS may modify the scope of the shortlist of physical channels from information broadcast from the 
network and held in its non- volatile storage as follows: 

1) by adding to the compass of the hunting sequence channel numbers received in C_BCAST 
(AnnounceAVithdraw) PDU from the selected network; 

2) by removing from the compass of the hunting sequence channel numbers received in C_BCAST 
(AnnounceAVithdraw) PDUs from the selected network. 

One strategy illustrated in figure D.1 entails hunting the list of physical channel numbers sequentially (e.g. from the 
randomly chosen list position to the highest then circling to the lowest list position) but beginning the hunting stage at a 
random position in the sequence of physical channel numbers. The shortlist is sampled twice, the first loop being 
exercised looking for a TSCC whose signal strength exceeds a defined value (L_Short). 

Another possible strategy entails hunting the complete shortlist of physical channel numbers sequentially (e.g. from 
lowest list position to highest list position) recording the signal strength and/or BER. After sampling all channels in the 
list the MS chooses the most appropriate TSCC. 

D.1 .2.3.1 Conditions to enter a Short Channel Hunt 

A MS enters the "short hunt sequence": 

a) immediately after switch-on, provided that the MS holds no valid information of previous activity on the 
selected network; 

b) when the user indicates a change of selected network, provided that the MS holds no valid information of 
previous activity on the selected network. 

The MS may enter the "short hunt sequence" at any time during the "comprehensive hunt sequence", at the MSs 
discretion. 

The MS should not make any transmissions on a TSCC located during the "short hunt sequence" until it has verified 
and confirmed the channel in accordance with the procedures specified in clause 6.3. 

Upon unsuccessful completion of the "short hunt sequence" the MS enters the "comprehensive hunt sequence", except 
when the "comprehensive hunt sequence" has been suppressed by MS personalization for a network. 
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D.1 .2.4 Comprehensive Hunt Sequence 

The "comprehensive hunt sequence" shall include every channel within the range set by the lowest and highest channel 
numbers set by the network personalization, held in the MSs fixed non- volatile storage. 

D.1 .2.4.1 Conditions to enter a Comprehensive Channel Hunt 

A MS enters the "comprehensive hunt sequence" when a "short hunt sequence" has been unsuccessfully completed. 

A MS may repeat the "comprehensive hunt stage" until such a time as a physical channel which satisfies the TSCC 
confirmation tests specified in clause 6.3 is found. 

The MS shall not make any transmissions on a TSCC located during the "comprehensive hunt sequence" until it has 
confirmed the channel in accordance with the procedures specified in clause 6.3. 

At any time during the "comprehensive hunt sequence" a MS may undertake a "short hunt sequence", or sample any 
physical channels that the MS is able to determine may be successful, returning to the "comprehensive hunt sequence" 
in the event that these choices is unsuccessful. 

It shall be possible to suppress the "comprehensive hunt sequence" by MS network personalization. In this case the MS 
shall remain in the "short hunt sequence" with the acquisition threshold set to a level L_Squelch until such time as a 
channel which satisfies the TSCC confirmation tests specified in clause 6.3. 

D.1 .2.5 Receiver Sensitivity During Control Channel Acquisition 

The MS should not attempt to become active on any physical channel for which the received signal level (or signal 
quality) is less than the specified acquisition threshold. 

The acquisition threshold L_SHort is set to a signal level within the range L_Upper_SHort to L_Lower_SHort at the 
input of the receiver (or an equivalent if the receiver measures signal quality). 

L_Squelch is set at a level determined by the MS manufacturer which enables unsuitable physical channels to be 
rejected on which the received signal is inadequate for a suitable grade of service (or an equivalent if the receiver 
measures signal quality). 

NOTE: The MS may be unable to determine the received signal level but may use other methods such as bit error 
measurements to determine the signal quality. 
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Annex E (informative): 

Use of MSC and SDL diagrams 

E.1 Introduction 

The present document makes use of SDL and MSC diagrams to complement textual behaviour descriptions in DMR 
Part Trunking Services and Facilities Protocol. 



E.2 Principle 



The MSC and SDL diagrams express the same behaviour (requirement) as defined by the textual description so they 
only complement the textual description in order to provide an alternative perspective on a requirement. The 
development of these diagrams also may also support validation of the textual description, e.g. identifying missing stop 
of a timer when other expected behaviour occurs before timeout. 



E.3 Notation 

The MSC-diagrams make use of the following constructs illustrated in figure E.l. 



Message exchange between 
instances 



Start timer 



_^/ Stop timer 



_^ Timer Expiry 



Figure E.1 : SDL Notation 

1) Message exchange between instances (line with arrow associated with message name and parameters in 
parentheses). 

2) Start timer (horizontal line with hour-glass). 

3) Stop timer, (horizontal line with 'x'). 

4) Timeout (horizontal line with arrow and hour-glass). 

5) The optional inline construct, (rectangle with keyword 'opt' in upper left corner). The meaning of the optional 
inline construct is that the contained behaviour is optional to occur. 

6) The alternative inline construct (rectangle with keyword 'alt' in upper left corner and dotted separation lines). 
The meaning of this construct is that each of the alternatives divided by the dotted line is a possible behaviour 
of which exactly one is to occur for the MSC. 
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In the SDL diagrams only basic process behaviour symbols are used, that is state, input, output, decision, timer start, 
and timer stop symbols. 
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